[Seaside] JSObject printOn:

[Lukas Renggli]

> Shouldn't JSObject>>printOn: be something else, so printOn: can show
> information in the inspector? And

The use of #printOn: has legacy reasons.

> addLoadScript: anObject
>        loadScripts := loadScripts copyWith: anObject.
>        ^ anObject
>
> could more meaningfully reference aJSObject ?

Also it makes it possible to use any objects (like strings themselves)
can be added as load scripts. Furthermore it avoids a naughty
dependency: #addLoadScript: is in Seaside-Core, while JSObject is in
an optional extra package.

> As we rely on examples instead of documentation, these little things can
> really impede 'getting' what a class is doing, IMHO.

You are not the first one to complain about the (mis)use of #printOn:.
Personally, I don't think it is too bad: it clearly communicates what
the object is representing, a proxy for the Javascript representation
it prints to.

I agree that it would probably be better to change it to something like

    a JSObject(mock)

where in brackets the Javascript representation is given.
Unfortunately this is not easily possible given the wide application
of this pattern in various internal and external Seaside Javascript
libraries for over 4 years now.

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch