Re: Object.Attach silently does nothing for a plain observer class

[Alarch <alarch@xxxxxxxxx>]

On Thu, 10 Sep 2026 10:01:04 +0200
Benoît Minisini <benoit.minisini@xxxxxxxxxxxxxxxx> wrote:

> Le 09/09/2026 à 11:00, Alarch a écrit :
> > Dear Benoît, dear all,
> > 
> > A separate report from my other message about GB_BASE (keeping one
> > topic per mail) - another gotcha from the same small llhttp-based
> > HTTP server proof-of-concept, this time on the Gambas language side
> > rather than the native-component side.
> > 
> > I wanted a small custom class (one instance per accepted
> > connection) to receive both a Socket's "Read" event and my own
> > component's custom event, so I used:
> > 
> >      Object.Attach(Me, hSocket, "Socket")
> >      Object.Attach(Me, hParser, "Parser")
> > 
> > expecting Socket_Read and Parser_MessageComplete to fire on Me.  
> 
> This is the other way around:
> 
> Object.Attach(Object, ObserverObject, EventName)
> 
> The first argument is the object that sends the event. The second 
> argument is the object that receives the event.
> 

Dear Benoît,

Thank you - that's exactly the mistake. I had the first two arguments
backwards, and I owe the list a correction rather than just a quiet fix,
since my original message stated a wrong conclusion as if it were a
confirmed limitation.

I went back and tested the corrected order for real:

    Object.Attach(hSocket, Me, "Socket")

with Me being the exact same plain hand-written .class as before - no
Event declaration, no Inherits Observer, nothing special about it. It
works perfectly: Socket_Read fires on Me right away. So my claim that "a
plain .class can never receive anything through Object.Attach" was
simply wrong - it receives events just fine as the *second* argument. The
is_observer/n_event>0 requirement in OBJECT_attach() that I quoted is
real, but it applies to the first argument (the event source), not to
the observer as I'd assumed - which makes much more sense in hindsight,
since that's the object whose own events are being routed through this
mechanism in the first place.

For the record, in case anyone finds the original thread later: the
correct mental model is

    Object.Attach(Source, Observer, Name)

and events on Source then call Name_EventName methods on Observer - so
Object.Attach(hSocket, Me, "Socket") calls Me.Socket_Read(), not
Socket.Read on some attached "Me" event. Requiring Source's class to
have real events (or be the built-in Observer) makes sense once read
that way: it's Source that needs something to route.

Sorry for the noise, and thank you for catching it quickly rather than
letting me build further on a wrong premise.

Best regards,
Marc