Merry Christmas (was Re: [Brain-list] I am still alive ... :-)

[Clemens H. <c.h...@gm...>]

Manuel Tomis writes:
> Hi Clemens

Hi Manuel,

> > o If I try to access a method of slot that is not in the common
> >   hashtable a left-to-right depth-first lookup will be performed.
> What I was thinking of is to try to find a more explicit way of
> resolving conflicts, rather that them being resolved by the order in
> which parents are defined (which is what is being done right now),
> maybe something along the redirect:to: proposal you once
> mentioned. But I am not sure yet.  Do you think that the
> implicit/order-of-definition style of resolution would be
> satifactory and clean enough?

Hmmm ... the best would be if you could find that there are ambiquity
during message lookup you issue an error! To resolve this one would
have to use redirect:to: message.

But I remember you once said that you could easily find out such
issues. So I thought to propose left-to-right depth-first. I still
think, my first proposal would be better. Perhaps caches could help
here. If you build the cache not if message lookup takes place but if
prototype is assigned?

That should not happen too often, and therefore there should be no
performance penalty, should it?

(...)

> But leaving the above comments aside, I decided I like your :symbol
> proposal, for the reasons you have put(ability to have some more
> kinds of symbols as literals, and the freeing up of # for future
> use).
> Also it is now possible to define any symbol, by following the :
> with a string literal like this (could have been done with old
> syntax too but for some reason I had forgotten to do it):
>   :"foo bar +" println
>   =>foo bar +
>   
> Updated version is in CVS.

Woa! Thanks for it. It is like Xmas, isn't it? ;-)

I have checked out and had a look onto it! I find the syntax very nice
now. Message selectors with parameters become really eye catching
now ... I like this. :-)

> > I understand! But could we find a way to fake this. IMHO s2 should
> > behave like a String although it is not a String. Perhaps if
> > prototype is native one, a cloned copy should be stored together
> > with the object so that such messages could be send to the native
> > object (a bit like your old prototype concept of the old Brain)?
> 
> There are problems:

(... problem description deleted ...)

Hmmm ... perhaps I have not properly described my solution. But I have
thought more about it. Perhaps we should say, that Brain objects can
serve both as prototypee and delegatee, whereas native objects could
only be used as delegatee? Would that solve the problems you've
mentioned above?

This and the fact that you use a cache for message lookup that would
be filled via prototype/delegate assignment could be promising
solution of our problems, couldn't it?

> > Just a quick thought! I do not know if it is a clever idea! But if it
> > is, that native object should be hidden and inaccessible from the
> > outside.
> I am not sure exactly what you mean here, can you tell me more?

Nearly the same as I described above in this mail. But if I use a
native object as prototype, perhaps turning this to delegation to an
instantiation of the prototypee. But that would be hidden so that I
couldn't even see that this happen. I would still believe that
e.g. String became a prototype of my object whereas in reality an
instance of it becames a delegatee.

But with my proposal above with the 'native objects only delegatees'
this would perhaps not necessary anymore?

(...)

> If I understand correctly you are suggesting that we put the on:do:
> method in the Exception objects here? Does that mean that when an
> exception is raised, every handler block should be evaluated until a
> match is found? If so then I think there are two problems:
> o May be slower that alternative
> o No one restricts what kind of code can be in the handling block,
>   which means that if for example we put a 'println' in the first
>   line before 'exception' it will be executed whether any of the
>   handlers below match the thrown exception or not, which is
>   probably not such a clean solution.

You are right! But do I have to use a new Handler instance for
this. Would a singleton Handler object enough?

> Anyways, I have implemented the scheme I proposed in my last mail,
> and it is in CVS.  As always if any problems arise, we will just
> change everything :-)

:-) :-) :-)

> > BTW: We should try to decide whether Brain works with methods or
> > messages. I would vote for the last, whereas e.g. on:do: would be a
> > selector or message name.
> Forgive my ignorance, but could you tell me the difference?

Not too much. But perhaps this proposal is already to late anyway, as
you call it:

   obj method: :foo is: { ... }.

So you implicitly have already decided to call the whole stuff
'method'. The true difference is not to big, IMHO. For me, a method is
more like a subroutine in C++ or Ruby or even Python. 

A message would be a name, that is associated with some code! That
would be more like Smalltalk, Objective-C or Brain, IMHO. It is really
difficult for me to tell the difference. A message has code associated
to it, whereas a method *is* code. Ahhh too confusional, sorry about
it. Perhaps better forget it.

But to speak the truth, something like:

  obj message: :foo do: { ... }.

looks also not ugly! ;-)

But be it as it be, we should not intermixing these both terms. Either
we use methods *or* we use messages. But not both.

Another issue: I think we really should thinking about some
nameswitching. Not necessarily for new Brain, but for old one. I never
liked the idea that C-Brain is version 0.5.2 whereas C++-Brain become
version 0.6. That is a bit cheating IMHO, as nearly all was new
implemented. That should deserve an own version-number-chain.

Perhaps calling the C-Brain a Brain study and let the new one begin
with 0.1 as it should?


> Manuel
Clemens.


PS: Merry Xmas for you, your family and friends and all
    friends-in-Brain!

-- 
Clemens Hintze  mailto: c.h...@gm...