Le 05/07/2013 15:31, Igor Stasenko a écrit :
On 5 July 2013 15:22, Igor Stasenko <[email protected]> wrote:
On 5 July 2013 11:03, Goubier Thierry <[email protected]> wrote:
Could you rather test for unability to get the source of the method and
raise a NB-defined error? So that I could write a fallback on non-NB code
with a on: do:. Please :)
(it would then both handle startup related errors and unreadable sources as
well).
And with a backport to 2.0, because the odds of seeing an Opal based
solution on 2.0 are fairly low.
the problem is that you will get same error when you put wrong name
into signature
or when no sources avail e.g.:
foo: bar
^ self nbCall: #( void foo (int baz) )
will give same error (unable to find binding for name 'baz' in given context).
Of course. I could do with having the same error for both and knowing
that when developping and testing I would get it for stupid syntax
errors and in production to handle a real situation.
If its fine to you, i can do it.
Maybe I can try myself to see if I can write, before entering that
loader stuff, a correct test which raises an error if the method source
isn't available.
Is there a real, practical difference between "at compilation time" and
"when receiving MethodAdded event"? i.e. is the complexity added in the
compilation process worthwhile?
the problem is that you may not always receive MethodAdded event,
because different tools putting different meaning into "this should be
compiled silently".
This is outstanding issue in Pharo.. and that's the main reason why i
would go with compiler (like
that i have guarantee that instance of CompiledMethod is well-formed,
and don't need to rely on
3-rd party toolchain to deliver notification to me.
You mean that hacking support into the third party compiler isn't 3rd
party toolchain :)
and besides, we need such hook mechanism in Compiler anyways (for many
other use cases)
and so, it will be not "renting a Boeing for single passenger"
oh.. and i forgot about most important aspect of it:
i don't wanna see
<primitive: #primitiveNativeCall module: #NativeBoostPlugin error:
errorCode >
in code, instead if wanna use
<native>
(or similar),
which admit, much more concise, elegant and user-friendly, and hides
unnecessary implementation detail.
I remember seeing people introducing syntax extensions inside smalltalk
methods in VisualWorks, would that work as well ? Customize on a per
class / per method which compiler we should use.
Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
