Ruby and OOP-design (question of an old "procedural person" ;)

[Meino Christian Cramer]

Hi !

I have a newbie question on OOP-design:

What I have is a large ASCII-File, a list of about 11000 shortwave
broadcasters. Each line contains the informations about one
transmitter hold in a long string without any delimiters.

It is specified, what offsets into a line are to be used to cut off
the informations one would need about a broadcaster.

What I want to do is to read the whole file into memory, put each
information into a sperate "field" to get rid of those
"information-one-liners" and then I want to sort the whole thing by
frequency first and by on-air-time then.

What I done so far is (pseudo-code):

--------------------

class SWFILE( file)
open the file
@ist=List.new
foreach line do
format line by expressions like @time=line[<start>..<end>]
transmitter=Broadcaster.new( @freq, @station, @time.....)
List.append( transmitter )
end foreach
end

class Broadcaster
def initialize( freq, station, time.....)
@freq = freq
@station = station
@time = time
...
end
end

class List
def initialize
@list=Array.new
end

def append( broadcaster)
@list.push( broadcaster)
end
end

a=SWFILE.new( "<filename>" )

--------------------


This works so far....

Then I read about the new sort_by feature. This is exactly what I
need!

But sort_by needs an array as input.

And my "list"-object is an object (or a duck, which quaks ;) holding
and array...or what...or .... I got confused here.

Furthermore I am really not sure, whether I have generated as
"class-ified" program, which is programmed in a procedural way only
or ... ?

Two questions:
What I have to feed where into the structure to sort the broadcasters
by frequency first and then by on-air-time ?

Is this "design" ok (in the sense of OOP)?

Kind regards from a confused duck, which quaks,
Meino

[Meino Christian Cramer]

From: Florian Frank <flori@nixe.ping.de>
Subject: Re: Ruby and OOP-design (question of an old "procedural person" ;)
Date: Sat, 9 Aug 2003 17:50:09 +0900

Hi Brian !

*** Thank you very much for your mail and your kind words! ***

After I saw your solution, I got the flat-hand-on-the-forehead-effect ;)

I got stuck in "after the object generation" and could only
thought of "TRAPPED!"... :)

But now it is clear, what I have to do!

Thank you very much indeed!
Kind regards and have a nice weekend!
Meino

[Martin DeMello]

Florian Frank <flori@nixe.ping.de> wrote:

>
> def <=>(other)
> (self.freq <=> other.freq).nonzero? || other.time <=> self.time
> end

Shouldn't that be

def <=>(other)
a = (self.freq <=> other.freq)
a.nonzero? ? a : (other.time <=> self.time)
end

since calling nonzero? collapses [-1,1] to 'true'.

martin

[Martin DeMello]

Kent Dahl <kentda+news@stud.ntnu.no> wrote:

>
> That was my gut reaction at first but:
> $ ruby1.8 -v -e "p( -5.nonzero?, 5.nonzero?, 0.nonzero? )"
> ruby 1.8.0 (2003-08-04) [i686-linux]
> -5
> 5
> nil

*blink*

Okay, I'm officially Surprised. Seriously, I don't see this as a good
thing - ? methods ought to be strictly boolean IMO, and not rely on the
'value' of true. Otherwise, some of their self-documenting nature is
lost.

martin

[Florian Frank]

On 2003-08-09 19:31:49 +0900, Kent Dahl wrote:

> That is the beauty of only nil and false being false...

Yep. In Perl it's a common idiom to do something like
@a = sort { $a->foo <=> $b->foo || $a->bar <=> $b->bar } @a;
to sort @a because 0 is also false. But the Ruby Way seems to be less
hackish to me than Perl's approach.

Consider this in Perl:

0 || "false" => "false"

"0" || "false" => "false"

"00" || "false" => "00"

00 || "false" => "false"

The last example interprets 00 as octal 0 and thus false, but the string
"00" is just a string that consists of two chars and it happens to be
true. The string "0" is interpreted as zero none the less. In any case
you could add 1 to both so that a number is returned.

"0" + 1 => 1
"00" + 1 => 1

It's funny that Ruby looks like Perl but if you go into the details you
realize that it has a much better way to achieve the nice things without
having to carry the nasty things.

--
Premature optimization is the root of all evil in programming.
-- C.A.R. Hoare

[Martin DeMello]

ts <decoux@moulon.inra.fr> wrote:

>>>>>> "M" == Martin DeMello <martindemello@yahoo.com> writes:

>
> M> Okay, I'm officially Surprised. Seriously, I don't see this as a good
> M> thing - ? methods ought to be strictly boolean IMO, and not rely on the
> ^^^^^^^
> What is this ?
>
> svg% ruby -e 'p Boolean # :-)'
> -e:1: uninitialized constant Boolean (NameError)

The superclass manque of TrueClass and FalseClass :)

martin

[Martin DeMello]

Kent Dahl <kentda+news@stud.ntnu.no> wrote:

>
> Not yet on the duck typing train, I see.
>
> The ?-methods are still self-documenting in the sense that they tell you
> how you can use the result: as a boolean. That is a type, as in "I may
> be used in conditionals", and not a class, as quite evident by the lack
> of the Boolean common ancestor.

Well and good, but they don't document the fact that the return value
can be used as anything other than a boolean. Duck typing or no, I find
it conceptually messy to have a method called nonzero? return self
rather than true - compare nil? and zero?. Using the value of self feels
like relying on an undocumented side effect. (I feel the same way about
! methods returning nil rather than self when they haven't made a
change).

martin

[Kent Dahl]

Martin DeMello wrote:

> Kent Dahl <kentda+news@stud.ntnu.no> wrote:
>

>>Not yet on the duck typing train, I see.
>>
>>The ?-methods are still self-documenting in the sense that they tell you
>>how you can use the result: as a boolean. That is a type, as in "I may
>>be used in conditionals", and not a class, as quite evident by the lack
>>of the Boolean common ancestor.

>
>
> Well and good, but they don't document the fact that the return value
> can be used as anything other than a boolean.

You're asking alot from a mere method name and a single character. For
my special class, I might be able to use what I recieve from a to_s or
to_str in a special way, and I'll have to document it. The important
thing NOT to break, is how it works in the more general term.

Consider inheritance: You should comply with the interface of the
superclass for substitutability. However, you may augment and extend it
as long as it is still possible to substitute a parent object with a
child object.

nonzero? just does this using core design decisions of Ruby (nil and
false are only false values) instead of classes.

> Duck typing or no, I find
> it conceptually messy to have a method called nonzero? return self
> rather than true - compare nil? and zero?.

Well, we sure wouldn't want nil? returning self instead of true. Then it
would only return nil or false. :-)

As for zero?, I guess it just wasn't useful enough to return self. Just
what will you do with 0, 0.0, Rational(0,1) or any other zero that is
returned? The nonzero? may return values from a much bigger set, and
thus has lots of useful chaining possibilities.

> Using the value of self feels
> like relying on an undocumented side effect.

Now I know Ruby is easy to read, but we can't have _all_ the
documentation be Ruby source code. :-)
[url]http://www.rubycentral.com/book/ref_c_numeric.html#Numeric.nonzero_qm[/url]

> (I feel the same way about
> ! methods returning nil rather than self when they haven't made a
> change).

Are you saying the usage of ? and ! should be restricted to only the two
protocols/types/interfaces? I.e.
? => result either true or false and
! => self if modified, nil if unmodified
That would be a huge blow against the readability potential of Ruby
code, IMHO:

Real life:
- "Have you found the answer to life, the universe and everything?"
- "Yeah, it's 42."
Ruby code:
adams.found_answer? #=> 42

--
(\[ Kent Dahl ]/)_ _~_ _____[ [url]http://www.pvv.org/~kentda/[/url] ]_____/~
))\_student_/(( \__d L b__/ (pre-) Master of Science in Technology )
( \__\_õ|õ_/__/ ) _)Industrial economics and technological management(
\____/_ö_\____/ (____engineering.discipline_=_Computer::Technology ___)

[Hal E. Fulton]

----- Original Message -----
From: "Martin DeMello" <martindemello@yahoo.com>
Newsgroups: comp.lang.ruby
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Saturday, August 09, 2003 7:52 AM
Subject: Re: Ruby and OOP-design (question of an old "procedural person" ;)

> Well and good, but they don't document the fact that the return value
> can be used as anything other than a boolean. Duck typing or no, I find
> it conceptually messy to have a method called nonzero? return self
> rather than true - compare nil? and zero?. Using the value of self feels
> like relying on an undocumented side effect.

But as long as it isn't false or nil, it *is* true in effect.
And it's far from undocumented.

Yet in a way I sympathize... where I *would* feel funny is if
I made use of the numeric value returned rather than just
checking its truth... but I could probably get over even that.

> (I feel the same way about
> ! methods returning nil rather than self when they haven't made a
> change).

There we're in full agreement. I see the rationale for this, but
I *never* use the test for nil here (nor have I ever felt the
need to). All this does for me is prevent method chaining in
certain (fairly obscure) circumstances.

Hal

--
Hal Fulton
[email]hal9000@hypermetrics.com[/email]

[Martin DeMello]

Hal E. Fulton <hal9000@hypermetrics.com> wrote:

>

>> Well and good, but they don't document the fact that the return value
>> can be used as anything other than a boolean. Duck typing or no, I find
>> it conceptually messy to have a method called nonzero? return self
>> rather than true - compare nil? and zero?. Using the value of self feels
>> like relying on an undocumented side effect.

>
> But as long as it isn't false or nil, it *is* true in effect.
> And it's far from undocumented.

I just said it *felt* like using an undocumented side effect, since it
embraces-and-extends what I've been thinking of as the implicit contract
of a ? method.

> Yet in a way I sympathize... where I *would* feel funny is if
> I made use of the numeric value returned rather than just
> checking its truth... but I could probably get over even that.

And likewise it feels funny when I see it in someone else's code. It may
be useful, but so are a lot of other things that didn't make it into
ruby because the semantics conflicted with the name.

martin

[Dan Doel]

>>>(I feel the same way about
>>>! methods returning nil rather than self when they haven't made a
>>>change).
>>>
>>>

>>Are you saying the usage of ? and ! should be restricted to only the two
>>protocols/types/interfaces? I.e.
>>? => result either true or false and
>>
>>

>
>Yes
>
>
>

>>! => self if modified, nil if unmodified
>>
>>

>
>! => self always. Frinstance, why can't we have something like
>
>Module Modified
> def modified?
> true
> end
>end
>
>Module UnModified
> def modified?
> false
> end
>end
>
>def method!
> if changed?
> self.extend(Modified)
> else
> self.extend(UnModified)
> end
> self
>end
>
>
>

>>That would be a huge blow against the readability potential of Ruby
>>code, IMHO:
>>
>>Real life:
>>- "Have you found the answer to life, the universe and everything?"
>>- "Yeah, it's 42."
>>Ruby code:
>> adams.found_answer? #=> 42
>>
>>

>
>adams.found_answer? #=> true, false
>adams.answer #=> 42, nil
>
>Far more readable, IMO - in fact, it was the unintutive reading of a.nonzero?
>that took me aback in the first place.
>

But why should ? methods be required to return solely true or false?
Isn't it enought to require that they
return objects that evaluate to true or false appropriately?

I agree that it's all right to specify that ? methods shouldn't be
required to return values other than true or
false, but I don't think the opposite is true. What I'm saying is that
the return values of ? methods should
only be used in boolean situations, but they shouldn't necessarily be
required to be booleans. Using the
return values as other than booleans would probably be considered
unsupported, since any object that
evaluated equivalently could be used to replace the current return value
and have the function act
equivalently for its intended purpose.

The only place you gain with having ? methods return solely true or
false is when you're using irb, which
isn't exactly for polished applications (correct me if I'm wrong), or if
you're doing "puts blah?" directly,
in which case you should really be outputting a more coherent
error/diagnostic message anyway.

And if you go back to ruby and duck typing, if foo? returns something
that evaluates to true/false, then
it shouldn't matter if it actually is true/false or not.

Cheers

- Dan

[Martin DeMello]

Dan Doel <djd15@po.cwru.edu> wrote:

>
> I agree that it's all right to specify that ? methods shouldn't be
> required to return values other than true or false, but I don't think
> the opposite is true. What I'm saying is that the return values of ?
> methods should only be used in boolean situations, but they shouldn't
> necessarily be required to be booleans.

But there's no way of enforcing the latter.

> Using the return values as other than booleans would probably be
> considered unsupported, since any object that evaluated equivalently
> could be used to replace the current return value and have the
> function act equivalently for its intended purpose.

Yes, except that it's supported and used :) If it were a hack someone
came up with I'd think it ugly, but be unbothered by it.

> And if you go back to ruby and duck typing, if foo? returns something
> that evaluates to true/false, then it shouldn't matter if it actually
> is true/false or not.

Yes if there's a specific documented and relied-on non-'true' true
value. Not sure why I feel so prescriptive about this issue, but I find
the whole thing very nonRubyish in the way it tries to pack two pieces
of information into a single primitive value.

martin

[dblack@superlink.net]

Hi --

On Sun, 10 Aug 2003, Dan Doel wrote:

> But why should ? methods be required to return solely true or false?
> Isn't it enought to require that they
> return objects that evaluate to true or false appropriately?

Jumping in with semi-devil's-advocate point:

One situation I can think of in which it would be handy to rely on this
would be:

if a.nil? == b.nil?

which of course could also be written:

if (a.nil? && b.nil?) ||! (a.nil? || b.nil?)

or something, but obviously version 1 is nice and concise. Then again,
it's a pretty marginal case, I guess.


David

--
David Alan Black
home: [email]dblack@superlink.net[/email]
work: [email]blackdav@shu.edu[/email]
Web: [url]http://pirate.shu.edu/~blackdav[/url]

[dblack@superlink.net]

Hi --

On Sun, 10 Aug 2003, Martin DeMello wrote:

> Dan Doel <djd15@po.cwru.edu> wrote:
>

> > And if you go back to ruby and duck typing, if foo? returns something
> > that evaluates to true/false, then it shouldn't matter if it actually
> > is true/false or not.

>
> Yes if there's a specific documented and relied-on non-'true' true
> value. Not sure why I feel so prescriptive about this issue, but I find
> the whole thing very nonRubyish in the way it tries to pack two pieces

^^^^^^^^^^
(You mean non_Rubyish, of course :-)

> of information into a single primitive value.

But isn't that true of all values in Ruby? Meaning, they all pack
boolean information intor themselves along with whatever else they
are.


David

--
David Alan Black
home: [email]dblack@superlink.net[/email]
work: [email]blackdav@shu.edu[/email]
Web: [url]http://pirate.shu.edu/~blackdav[/url]

[Martin DeMello]

[email]dblack@superlink.net[/email] wrote:

>> Yes if there's a specific documented and relied-on non-'true' true
>> value. Not sure why I feel so prescriptive about this issue, but I find
>> the whole thing very nonRubyish in the way it tries to pack two pieces

> ^^^^^^^^^^
> (You mean non_Rubyish, of course :-)

of course :) or even non_rubyish

>> of information into a single primitive value.

>
> But isn't that true of all values in Ruby? Meaning, they all pack
> boolean information intor themselves along with whatever else they
> are.

Not really - the boolean information usually acts as an existence test
for the value. Here, by the semantics of nonzero?, the value *is* a
boolean, so packing another value in for the sake of convenience feels
wrong. IMO, this would be better in a 'nonzero' method (as opposed to
'nonzero?'), reading 'a.nonzero?' as 'is a nonzero?' and 'a.nonzero' as
'return the nonzero part of a' (by analogy with, say, Complex#im). Then
if a is zero, the nonzero part of a could safely be said to be nil, and
in a boolean context it'd be a proper existence test, and I at least
would be happy :)

martin

[Dan Doel]

[email]dblack@superlink.net[/email] wrote:

>Hi --
>
>On Sun, 10 Aug 2003, Dan Doel wrote:
>
>
>

>>But why should ? methods be required to return solely true or false?
>>Isn't it enought to require that they
>>return objects that evaluate to true or false appropriately?
>>
>>

>
>Jumping in with semi-devil's-advocate point:
>
>One situation I can think of in which it would be handy to rely on this
>would be:
>
> if a.nil? == b.nil?
>
>which of course could also be written:
>
> if (a.nil? && b.nil?) ||! (a.nil? || b.nil?)
>
>or something, but obviously version 1 is nice and concise. Then again,
>it's a pretty marginal case, I guess.
>
>
>David
>
>
>

That is a good example.

Does ruby not have exclusive or? I can't remember at the moment. If it
did, I think the top is the same
as:

unless a.nil? ^ b.nil?

Which is still somewhat unclear, I agree.

That's a good example, though.

- Dan

[Dan Doel]

Martin DeMello wrote:

>Dan Doel <djd15@po.cwru.edu> wrote:
>
>

>>I agree that it's all right to specify that ? methods shouldn't be
>>required to return values other than true or false, but I don't think
>>the opposite is true. What I'm saying is that the return values of ?
>>methods should only be used in boolean situations, but they shouldn't
>>necessarily be required to be booleans.
>>
>>

>
>But there's no way of enforcing the latter.
>

There's no static way of enforcing that ? methods can only return
booleans, either, since variables
are untyped in ruby. And since ? is just an extra symbol for including
in method names, I don't
think the interpreter should fail, since someone could be strange an do
something like

obj.what_is_a?

Which is ugly to you and me, but someone else might like it, I suppose.
:) All I'm saying is that
in either case, it's merely a convention either way, and people may
adhere to it or not.

>>Using the return values as other than booleans would probably be
>>considered unsupported, since any object that evaluated equivalently
>>could be used to replace the current return value and have the
>>function act equivalently for its intended purpose.
>>
>>

>
>Yes, except that it's supported and used :) If it were a hack someone
>came up with I'd think it ugly, but be unbothered by it.
>
>

Well, it shouldn't be used (probably). Go back and read my final post
on the duck typing thread;
I think it applies here. If a method's contract says, "returns a value
that is true or false depending
on blah" then the contract only guarantees true or false, so nothing
more can be used correctly.
If it says, "returns self when true, and nil when false," then those
values can be used correctly. If
it says, "returns true when true, and false when false," then you're
enforcing that programatically.

The ? doesn't define the contract, the person writing the method does.

>>And if you go back to ruby and duck typing, if foo? returns something
>>that evaluates to true/false, then it shouldn't matter if it actually
>>is true/false or not.
>>
>>

>
>Yes if there's a specific documented and relied-on non-'true' true
>value. Not sure why I feel so prescriptive about this issue, but I find
>the whole thing very nonRubyish in the way it tries to pack two pieces
>of information into a single primitive value.
>
>

I don't know that it's non-rubyish, but it is non-object oriented, in
some sense. Or perhaps not
non-object oriented, but it flies in the face of some standard of
"language purity." But ruby
already does that anyway by treating nil and false as false, and
everything else as true.

If the contract of ? methods is that they always return a true-value
when the condition is true,
or a false-value when the condition is false, then it doesn't really
make sense to return anything
other than true or false themselves (other than to save typing, because:

def nil?
self
end

is shorter than

def nil?
self ? true : false;
end

But that's not much of an argument). However, that may not always be
the explicit contract
of a ? method. Perhaps the convention needs to be changed, or perhaps
you need to re-
evaluate your concept of ? methods. That's not really for me to say one
way or the other.
However, I will say that if ? methods are meant to only be used as true
or false values,
then it shouldn't matter whether the values returned actually are true
or false (except in certain
circumstances where the fact that they aren't can be a real pain; see
David's devil's advocate
post), and that concept is very rubyish.

- Dan

[ts]

>>>>> "D" == Dan Doel <djd15@po.cwru.edu> writes:

D> def nil?
D> self
D> end

Sorry, but I really don't understand why you use #nil? because precisely
#nil? return true or false

The original problem was with #nonzero?

pigeon% ruby -e 'p 12.nonzero?'
12
pigeon%

pigeon% ruby -e 'p 12.zero?'
false
pigeon%


Guy Decoux

[Brian Candler]

On Mon, Aug 11, 2003 at 02:02:33AM +0900, [email]dblack@superlink.net[/email] wrote:

> > Does ruby not have exclusive or? I can't remember at the moment. If it
> > did, I think the top is the same
> > as:
> >
> > unless a.nil? ^ b.nil?
> >
> > Which is still somewhat unclear, I agree.

>
> I, however, no long agree with myself :-) I just forgot about ^.

However ^ is overloaded, so although it works when comparing false/true with
false/true, it doesn't with other things; especially since it doubles up as
a bitwise numeric operator too.

irb(main):001:0> 5 ^ false
TypeError: cannot convert false into Integer
from (irb):1:in `^'
from (irb):1

But it does treat 'nil' as 'false'. So you could say:

if (a && true) ^ (b && true)
...
end

which tests if both a and b are 'true' or both a and b are 'false' in the
Ruby sense of those terms, but it's still not very pretty. I think it would
be clearer to write

if (a && b) || (!a && !b)

It's not a problem with nil? anyway. If you want to check whether a and b
are either both zero or both nonzero, you could do

if (a == 0) == (b == 0)
...
end

The fact that nonzero? carries forward the original value, rather than just
'true', is IMO a nice touch which allows useful chaining of operations like
cmp. But that's just being pragmatic :-)

Cheers,

Brian.

[Dan Doel]

ts wrote:

>>>>>>"D" == Dan Doel <djd15@po.cwru.edu> writes:
>>>>>>
>>>>>>

>
>D> def nil?
>D> self
>D> end
>
> Sorry, but I really don't understand why you use #nil? because precisely
> #nil? return true or false
>
> The original problem was with #nonzero?
>
>pigeon% ruby -e 'p 12.nonzero?'
>12
>pigeon%
>
>pigeon% ruby -e 'p 12.zero?'
>false
>pigeon%
>
>

It was just an example. #nil? could be written that way, although then
it'd be pointless, since

if obj ...

Would be exactly the same as

if obj.nil? ...

The only difference would be some readability.

But you could substitute #nonzero?, #zero?, #respond_to?, or any ?
method for #nil? in my
post and I think it would still apply, except that you don't save any
typing for other methods.

- Dan