Chad Perrin wrote:
David Masover wrote:
> Oh, you mean you've actually defined things like 
> (nil.nil? == false)? That's not very smart.

Indeed, any logical premise is possibe until proven wrong. There are 
domains in which true == false, or 2+2=5 for that matter. They are yust 
not the domains you usualy work in. Your writing shows limited 
flexibility and rigidity that are the thing of the past.

>> Logically in OOM the term loosely means "the opposite".

> I have never heard it used to mean that, in computer science or 
otherwise.

Of course not - this is not hard to guess from your anything but 
enlightening arguments. The keyword in my definition of the term 
orthogonal is "loosely", which you missed despite including it in the 
quote. For OO and procedural programming the orthogonality comes to mind 
due to the fact that the first deals with vertical pyramid - structured 
organizations, while the other with flat object organizations.  It is 
not so much that these two are opposite, but they definitely are 
perpendicular to each other. The fact that each of these two 
organizations in their respective domains employ orthogonal operations 
makes them loosely opposite. Of course if you have trouble seeing what's 
orthogonal, you are at a loss here. If you would ever open Grady Booch's 
OOA/D or Ivar Jacobson's OO Software Engineering you would see countless 
occurrences of this term. In fact one of the first things you ever learn 
in Booch is about the orthogonality of the class and object structure, 
whereby each complex system can be viewed as both a class structure and 
as an orthogonal to it object structure.  Class exhibits a "is-a" 
relationship property while object structure its orthogonal or opposite 
"has-a" relationship. On the other hand Jacobson's analysis model is 
based on there dimensional space defined by three mutually orthogonal 
entities: behaviour, presentation, and information (data) ... Needless 
to say that the two OOM models were accepted by every other computer 
scientist and they subsequently use the term in question throughout 
their work. You really do not have to advertise your ignorance ;)



Chad Perrin wrote:
> Actually, he was probably misled by the fact that you keep 
> using the "fact" that Perl is a "procedural language" as a 
> means of attacking it, and holding up Ruby's OO-ness as 
> proof of its superiority, then follow that up by holding 
> up Booch as the standard of all that is good and right
> in the world of programming technique.

Indeed, Perl is a procedural language, and the OO is only its extension. 
You either did not read my posts or perhaps you want to ignore all the 
arguments that explain how OO is a bonus in Perl, and that it is far too 
much trouble to use. The true Perl power is in it's procedural features, 
and its OO extension spells trouble for every project that reaches the 
entry level complexity if managed by Ruby. It may appear that I have 
been too negative about Perl, but that is not really how I feel about 
it, namely, I love Perl but not for its OO features but for what it 
really is - and that undoubtedly is one of the pearls between the 
procedural languages. Hey, C can also be used as a language in OO 
environment thanks to its GNOME extension, and I can argue that C/GNOME 
combination is much more powerful than Perl's OO extension!
-- 
Posted via http://www.ruby-forum.com/.