attr

[Trans]

Thanks David,

Okay, I've been convicned that ! attr as defined is utterly useless. So
I'll drop it. Maybe someone will think of a good use down the line.

T.

 

[Trans]

Not exactly. But since Ruby can treat any object properly in

a boolean context, why waste some processing cycles on
conversion if not because of information hiding (i.e. prevent
leakage of a member value)?

Well, that wasn't my reasoning when I did it that way. I just thought
it should return boolean (or nil) as one would likely expect from a
?-method. But I see your point too. But perhaps this information hiding
provides it with some merit offsetting the down side of the extra
processing?

But you didn't have it either and apparently you missed
it, didn't you? ;-)

:-} He he. I suppose so. Well, it started with the casting and sort of
just grew from there.

T.

 

[Zach Dennis]

Thanks David,

Okay, I've been convicned that ! attr as defined is utterly useless. So
I'll drop it. Maybe someone will think of a good use down the line.

There is already a use, followed by a verb the ! signifies that the
receiver is going to be modified.

Zach

 

[David A. Black]

Hi --

There is already a use, followed by a verb the ! signifies that the receiver
is going to be modified.

It often does signify that, but it doesn't have to. Matz has
described it as follows:

In Scheme, every destructive operation has bang sign at the end of
the name. Ruby did not follow this principle, rather I choose to
put bang sign at the end of the name of methods which are more
dangerous than alternative.


David

 

[Robert Klemme]

Well, that wasn't my reasoning when I did it that way. I just thought
it should return boolean (or nil) as one would likely expect from a
?-method. But I see your point too. But perhaps this information hiding
provides it with some merit offsetting the down side of the extra
processing?

Probably. There is also the aspect of resource consumption: if a client
stores a boolean flag which is really a complex object of some type GC
cannot clear it although the owner might have released it already.

:-} He he. I suppose so. Well, it started with the casting and sort of
just grew from there.

As it often does.

Kind regards


robert

 

[Florian Gross]

There is also another form which I thought might be nice to have, a
getter/setter: If an argument is given it acts as a setter, if not it
acts as a getter. But I have no simple notion to use for it. At the
moment it can be done like this:

| attr :"a()"

But I'm not too sure about it.

That's perl style. It does not make sense in Ruby.

 

[Trans]

Sure, but it is occasionally useful, especially when creating classes
that have many optional "initialization" parameters. Here's the
traditional-styled version. I use "setter" for lack of a better word.

# attr_setter :a
#
# _is equivalent to_
#
# def a(*args)
# if args.size > 0
# @a = args[0]
# self
# else
# @a
# end
# end

T.

 

[Trans]

Update:

I've now fixed #attr to be backward compatible. The only caveat being
that one mustuse true (or false or nil) for it to work. ie.

| attr :a, "as if it were true"

will not work. But as Florian pointed out, this is fairly
insignificant.

The feature BTW is a bit extended. It can now take more than one
attribute as follows:

| attr :a, :b, :c, true

And all three will get writers too.

One last thing, it doesn't just create writers but the
"contra-positive" of the attributes you can give it. In other words:

| attr :a=, true

Will also create a reader. And

attr :a?, true

Will get a writer (#a=).

Note that casting can not be used with this notation. So

attr :a => :to_s, true

Will not work. This is b/c casted attributes must always be at then end
of the argument list (it's a hash after all).

Oh, one last thing. All the "attr_*" methods are still there but now
they accept casting and I've added #attr_tester (for #a? methods)

Hope you like. It will be available when I release Carats in a month or
two. (Sooner if I can find a helping hand.)

T.

 

[Gavin Kistner]

Why not "def a?() @a end"?

I personally always define them as:
def a?
!!@a
end

to ensure a boolean value is returned.

 

[Trans]

I personally always define them as:

def a?
!!@a
end

Nice, thanks.

T

 

[Vance A Heron]

If a set of documents need to be "approved" for
external release -
True means they're approved
False means they've been reviewed and are not allowed to be released
nil means they're not reviewed yes (and are not yet allowed to be
released).
V

 

[Martin DeMello]

I have failed to see when using three state's is needed. Could you
provide an example where "my_obj.a?" would behave different if nil/false
meant nil/maybe ?

It'd be nice to have an operator like || that only failed for nil - that
way 'false' valued variables wouldn't be splatted by the a ||= b idiom.

martin

 

[Robert Klemme]

It'd be nice to have an operator like || that only failed for nil - that
way 'false' valued variables wouldn't be splatted by the a ||= b idiom.

martin

Isn't #nil? sufficient?

foo = nil

5.times do
foo.nil? and begin
foo = false
puts "changed"
end
end

Kind regards

robert

 

[Martin DeMello]

Isn't #nil? sufficient?

foo = nil

5.times do
foo.nil? and begin
foo = false
puts "changed"
end
end

That's a lot more verbose, though. And personally, I've only ever used
||= for setting uninitialized values, so it'd definitely have been more
useful to have it distinguish between nil and everythingelse. I suppose
this would work:

class Object
def splat(other)
self.nil? ? other : self
end
end

foo = foo.splat 5

but I still like the <operator>= form.

martin