OpenEuphoria

Re: Splitting hairs with Ralf

• Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Apr 23, 1998
• 771 views

Looking at the subject, you sound a bit offended, and for this I apologize.
I sometimes sound pretty arogant it seems, but just consider it my lack of
expierence, I never ment to sound this way.



>Take a look at your last sentance, Ralf. Whether or not it *should* be that
way, it *is* in fact slower to do certain operations on elements of
structures than on a variable - slow enough for me to avoid it, if possible.

Yes, but you said structures weren't a good idea, because they were
currently very slow in Euphoria, and my point was, defined structures
*would* be fast, unlike undefined structures that we have to use now.

>On to the disagreement. Both my example, or the initial example *could*
have been OOP. Let's look at your argument:
>
>1. ...It would certainly not be more "pure"...
>
>I think my version encapsulates the information better, making it "purer".
Not more efficient - I never made that claim. But more pure, because it
hides the actual assignment. In the initial version, a function called
SetWin() is called to do an action - but the assignment portion of the
action is external to the method - clearly "less pure."

In any other OOP-language it is also an assignment hidden by a preproccesor.
I think an assignment at least shows us, that we do change the object, and
it is really not to the point. The point I made, was that the user now has
control over the data. It could save it to disk, print it out, clone it.
Plus it takes advantage of Euphoria's dynamic allocation and deallocation.

>2. ...but more "used" is the word your [sp] looking for.
>
>No, I think the first example is the more "used" - at least, by Euphorians.
Mind you, I've not done any statistical analysis on this. 

Well, neither have I, but doesn't many stuff from the Recent User's
Contribution list use handles. I mean, handles for virtual
screens(HHS-Mode19 Toolkit), for wave-channels (modwave), etc.

>3. Technically, it isn't even called OOP.
>
>Well, what's OOP?
>
>1. The data is encapsulated in objects.
>2. The methods are encapsulated in objects.
>3. Methods are passed.
>
>Inheritance, while nice, is *not* a requirement.

Well, I'm assuming you use an external library to manage your objects and
methods.
And using such a library the development of an object becomes, I must agree,
a bit easier, and produces code which is a bit more clear than it would be
in my case, but the use of the object would be extremely unnaturaly:

    procedure msg_box ()
        button my_button        -- This looks nice!
        button foo
        ...
        my_button = newButton ( {100,100}, GRAY, "CANCEL" )
        foo = setButton ( my_button, BUTTON_PRESSED )
        -- foo is now a clone of my_button, but in pressed state.
        ..
    end procedure

It looks nicer I think, but besider that: when the object gets out of scope
(end of procedure) euphoria unloads it, just like any other atom, sequence
or custom data type. A routine to unload would be unnatural.

>The only point left is the last: passing methods. You may disagree with my
syntax and say that a "pure" method would require a syntax like:
>
>   send_method( MyWindow, "btn1", COORDS, {50,20} )
>
>But I didn't ever claim that the example was "pure". By those standards,
C++ wouldn't even be OOP - something I'm not up to debating.

To be honiest, I care less what is would be more "pure", rather what would
be more "clear", "convient" and "consistent". I know the orginal SmallTalk
sends messages instead of methods, but thats just a syntactic thing, isn't
it ?

So there is our choice, what we consider more important:

    Clearity in object-code                                --> Handles
together with a library that manages it all.
    Clearity in usage & better performance     --> Object sequences.

Agreed ?

Ralf Nieuwenhuijsen
nieuwen at xs4all.nl