Smalltalk › Cincom › VisualWorks

[vwnc] Using a subclass of NameSpace?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Joachim Geidel

[vwnc] Using a subclass of NameSpace?

Dear fellow Smalltalkers,

I am afraid I need your help. I have an idea for enhancing JNIPort which
involves using subclasses of NameSpace to allow referencing Java classes
by name in Smalltalk code. (For insiders: it would be a bit different
from what JavaConnect does.) I need custom NameSpaces to be able to
resolve bindings in a different way, in this case dispatching class
lookup to a JVM (a JNIPort object which represents a Java VM attached to
the VisualWorks process).

While it is possible to create and use a subclass of NameSpace, I am
afraid that it is currently not supported by parcels and Store packages.

I managed to modify source code fileout and filein to work with my
custom NameSpace class - that was the easy part. Writing a custom
NameSpace to a parcel file can be done by overriding
#storeGeneralStructureOn: and using a different type symbol replacing
#commentedNameSpace. But for reading the parcel file, it is necessary to
modify CodeReader>>readNamedObjectDefinition. This method unfortunately
raises errors if the type symbol is not #nameSpace or
#commentedNameSpace, and it also creates an instance of NameSpace
without a way to map a type symbol to another class.

And there is more. Refactory.Browser.ExecuteCodeChange class hardcodes
the nameSpaceDefinitionMessages. Trying to move a custom NameSpace (with
a custom definition message) to another package fails because the
definition message is not in this list. It's not possible to extend the
list without creating an override for nameSpaceDefinitionMessages.

Sometimes I wish we had a Spring framework for making mechanisms like
these more extensible... (and I hope this remark doesn't start a flame
war :) ).

I have not tried to store a custom NameSpace in Store yet, but I somehow
suspect that it won't be easy to get it back out again once it's
inside... ;-)

Is there any way to make this work without too much hacking, or am I
stuck with
"(JVM findClass: 'java.my.package.MyClass') doSomething"
instead of
"java.my.package.MyClass doSomething"?

Thanks in advance,
Joachim Geidel

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck

Re: [vwnc] Using a subclass of NameSpace?

Your remarks about loading/storing the code holds equally for new
types of classes (new subclass hierarchies off Behavior).

>
> Is there any way to make this work without too much hacking, or am I
> stuck with
> "(JVM findClass: 'java.my.package.MyClass') doSomething"
> instead of
> "java.my.package.MyClass doSomething"?

Maybe try to fold it into methods:

JavaRoot java my package MyClass doSomething

The VM's inline caches are per send site, so this might be less
runtime overhead than it seems at first blush.

Not exactly pretty but this way you don't need to alter the code
import/export mechanisms of VW....

Yet another strategy could be to create your own Compiler class that
will interpret dotted names as java-specific if they are lower case,
this compiler could generate the bytecodes for
(JVM findClass: 'java.my.package.MyClass') doSomething
when it sees
java.my.package.MyClass doSomething

Downside is that you need to specify #compilerClass per class
hierarchy which might not be general enough for your usage patterns.

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Michael Lucas-Smith-2

Re: [vwnc] Using a subclass of NameSpace?

In reply to this post by Joachim Geidel

> Is there any way to make this work without too much hacking, or am I
> stuck with
> "(JVM findClass: 'java.my.package.MyClass') doSomething"
> instead of
> "java.my.package.MyClass doSomething"?
>
Check out ObjectiveC-2.0 Runtime in public store. It has a subclass of
NameSpace to hookup lookup Objc classes at runtime. It achieves this by
starting the namespace off as a regular namespace and changing its
behavior to the subclass at post-load time.

Cheers,
Michael
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Joachim Geidel

Re: [vwnc] Using a subclass of NameSpace?

In reply to this post by Reinout Heeck

Reinout, Michael,

thank you for your suggestions. I'll see how far I can get.

Using a customized Compiler was an option I wanted to avoid, but I'll
look into this. Maybe it's not as complicated as I thought.

I am not sure if I like the idea of using a chain of messages instead of
using the qualified names of the Java classes, which feels more natural
IMO. In addition, it's perfectly valid (VisualWorks-)Smalltalk syntax
already, and NameSpaces and Java packages are relatively similar
concepts (well, close enough anyway). That's why I found it so tempting
to base the solution on NameSpaces.

Using postLoad actions to transform normal NameSpaces into
JavaNameSpaces could work. I'll have to think about the details - I
don't want to have to write lengthy instructions for JNIPort users like
"after you have declared the JavaNameSpace, you will have to manually
code a postLoad action like this and a pre-save action like that etc."
If this can be automated, it's an option.

It seems that it will take some more weeks before this feature will be
finished. :-|

Cheers,
Joachim
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck

Re: [vwnc] Using a subclass of NameSpace?

On Feb 24, 2008, at 8:30 PM, Joachim Geidel wrote:
> Using a customized Compiler was an option I wanted to avoid, but I'll
> look into this. Maybe it's not as complicated as I thought.

If you implement this at the parser level it is probably easiest, just
spit out a parse tree with the rewrites incorporated. This way your
alterations stay decoupled from future bytecode changes.

Good luck!

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Georg Heeg

Re: [vwnc] Using a subclass of NameSpace?

In reply to this post by Joachim Geidel

Joachim,

Unlike Parcels, Store should not be of any problem here.

Upon Source Load: Store uses the source code of the definition string and
puts it into a blob. When the namespace is re-created, the definition string
is executed. Done.

Upon Binary Load: Binary load is the same as parcel load. Thus: When you fix
the parcel loading problem you have also fixed the binary load problem.

Georg

PS: I like your approach.

Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812
Tel. +49-3496-214328, Fax +49-3496-214712

> -----Ursprüngliche Nachricht-----
> Von: [hidden email] [mailto:[hidden email]] Im Auftrag
> von Joachim Geidel
> Gesendet: Sonntag, 24. Februar 2008 16:32
> An: vwnc-list
> Betreff: [vwnc] Using a subclass of NameSpace?
>
> Dear fellow Smalltalkers,
>
> I am afraid I need your help. I have an idea for enhancing JNIPort which
> involves using subclasses of NameSpace to allow referencing Java classes
> by name in Smalltalk code. (For insiders: it would be a bit different
> from what JavaConnect does.) I need custom NameSpaces to be able to
> resolve bindings in a different way, in this case dispatching class
> lookup to a JVM (a JNIPort object which represents a Java VM attached to
> the VisualWorks process).
>
> While it is possible to create and use a subclass of NameSpace, I am
> afraid that it is currently not supported by parcels and Store packages.
>
> I managed to modify source code fileout and filein to work with my
> custom NameSpace class - that was the easy part. Writing a custom
> NameSpace to a parcel file can be done by overriding
> #storeGeneralStructureOn: and using a different type symbol replacing
> #commentedNameSpace. But for reading the parcel file, it is necessary to
> modify CodeReader>>readNamedObjectDefinition. This method unfortunately
> raises errors if the type symbol is not #nameSpace or
> #commentedNameSpace, and it also creates an instance of NameSpace
> without a way to map a type symbol to another class.
>
> And there is more. Refactory.Browser.ExecuteCodeChange class hardcodes
> the nameSpaceDefinitionMessages. Trying to move a custom NameSpace (with
> a custom definition message) to another package fails because the
> definition message is not in this list. It's not possible to extend the
> list without creating an override for nameSpaceDefinitionMessages.
>
> Sometimes I wish we had a Spring framework for making mechanisms like
> these more extensible... (and I hope this remark doesn't start a flame
> war :) ).
>
> I have not tried to store a custom NameSpace in Store yet, but I somehow
> suspect that it won't be easy to get it back out again once it's
> inside... ;-)
>
> Is there any way to make this work without too much hacking, or am I
> stuck with
> "(JVM findClass: 'java.my.package.MyClass') doSomething"
> instead of
> "java.my.package.MyClass doSomething"?
>
> Thanks in advance,
> Joachim Geidel
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Niall Ross

Re: [vwnc] Using a subclass of NameSpace?

In reply to this post by Joachim Geidel

Dear Joachim et al,
I've had no problems in Store with my FirstFindNameSpace so far. It
is in package Porting-NameSpaces. It overrides

ExecuteCodeChange>>nameSpaceDefinitionMessages

which as you note is necessary.

Yours faithfully
Niall Ross

>Dear fellow Smalltalkers,
>
>I am afraid I need your help. I have an idea for enhancing JNIPort which
>involves using subclasses of NameSpace to allow referencing Java classes
>by name in Smalltalk code. (For insiders: it would be a bit different
>from what JavaConnect does.) I need custom NameSpaces to be able to
>resolve bindings in a different way, in this case dispatching class
>lookup to a JVM (a JNIPort object which represents a Java VM attached to
>the VisualWorks process).
>
>While it is possible to create and use a subclass of NameSpace, I am
>afraid that it is currently not supported by parcels and Store packages.
>
>I managed to modify source code fileout and filein to work with my
>custom NameSpace class - that was the easy part. Writing a custom
>NameSpace to a parcel file can be done by overriding
>#storeGeneralStructureOn: and using a different type symbol replacing
>#commentedNameSpace. But for reading the parcel file, it is necessary to
>modify CodeReader>>readNamedObjectDefinition. This method unfortunately
>raises errors if the type symbol is not #nameSpace or
>#commentedNameSpace, and it also creates an instance of NameSpace
>without a way to map a type symbol to another class.
>
>And there is more. Refactory.Browser.ExecuteCodeChange class hardcodes
>the nameSpaceDefinitionMessages. Trying to move a custom NameSpace (with
>a custom definition message) to another package fails because the
>definition message is not in this list. It's not possible to extend the
>list without creating an override for nameSpaceDefinitionMessages.
>
>Sometimes I wish we had a Spring framework for making mechanisms like
>these more extensible... (and I hope this remark doesn't start a flame
>war :) ).
>
>I have not tried to store a custom NameSpace in Store yet, but I somehow
>suspect that it won't be easy to get it back out again once it's
>inside... ;-)
>
>Is there any way to make this work without too much hacking, or am I
>stuck with
> "(JVM findClass: 'java.my.package.MyClass') doSomething"
>instead of
> "java.my.package.MyClass doSomething"?
>
>Thanks in advance,
>Joachim Geidel
>
>_______________________________________________
>vwnc mailing list
>[hidden email]
>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
>
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Joachim Geidel

Re: [vwnc] Using a subclass of NameSpace?

Dear Niall,

Niall Ross schrieb am 02.03.2008 00:16:
> Dear Joachim et al,
> I've had no problems in Store with my FirstFindNameSpace so far. It
> is in package Porting-NameSpaces. It overrides
>
> ExecuteCodeChange>>nameSpaceDefinitionMessages
>
> which as you note is necessary.

thank you for this information! However, the mere existence of your code
makes my idea less viable. If I would add another override of
nameSpaceDefinitionMessages, our packages would be incompatible, which I
would like to avoid.

So, I have an enhancement request for Cincom: Please store the
nameSpaceDefinitionMessages in a variable (class instance var?) such
that other developers can add their own selectors.

Best regards,
Joachim Geidel
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Niall Ross

Re: [vwnc] Using a subclass of NameSpace?

Dear Joachim,

> So, I have an enhancement request for Cincom: Please store the 
> nameSpaceDefinitionMessages in a variable (class instance var?) such 
> that other developers can add their own selectors.

ExecuteCodeChange uses these definition messages to decide which of its subclasses (e.g. AddNameSpaceChange) to use.  If its subclasses defined the messages and it searched for the subclass that would handle a given message, then you could easily add a fresh subsubclass e.g.
	AddNameSpaceChange subclass: #AddJNINameSpaceChange.
I suggest this instead of creating a variable since I think the problem is naturally static - a give code load has a fixed solution.

BTW, I should have mentioned in my last that dodging hardcoded NameSpace refs was necessary as you can see from my definition message

NameSpace>>defineFirstFindNameSpace: poolName private: isPrivate imports: importString category: newCategory attributes: attributes
	^self
		beFirstFindNameSpace: (self at: poolName ifAbsent: [nil])
		after: [self
					defineNameSpace: poolName
					private: isPrivate
					imports: importString
					category: newCategory
					attributes: attributes]

where I create or modify as a NameSpace, then use
    self changeClassTo: FirstFindNameSpace
to become a FirstFindNameSpace. This works for me because my specialised NameSpace only changes behaviour, not structure. So far, #modifySystem: has been good enough that I've seen no hiccough during the
    beFirstFindNameSpace:after:
block, but my usage has not been exhaustive.

HTH
          Yours faithfully
             Niall Ross

Dear Niall,

Niall Ross schrieb am 02.03.2008 00:16:

Dear Joachim et al,
   I've had no problems in Store with my FirstFindNameSpace so far.  It 
is in package Porting-NameSpaces.  It overrides

ExecuteCodeChange>>nameSpaceDefinitionMessages

which as you note is necessary.


thank you for this information! However, the mere existence of your code 
makes my idea less viable. If I would add another override of 
nameSpaceDefinitionMessages, our packages would be incompatible, which I 
would like to avoid.

So, I have an enhancement request for Cincom: Please store the 
nameSpaceDefinitionMessages in a variable (class instance var?) such 
that other developers can add their own selectors.

Best regards,
Joachim Geidel
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck

Re: [vwnc] Using a subclass of NameSpace?

On Mar 2, 2008, at 4:55 PM, Niall Ross wrote:

> Dear Joachim,
> > So, I have an enhancement request for Cincom: Please store the
> > nameSpaceDefinitionMessages in a variable (class instance var?) such
> > that other developers can add their own selectors.
>
> ExecuteCodeChange uses these definition messages to decide which of
> its subclasses (e.g. AddNameSpaceChange) to use. If its subclasses
> defined the messages and it searched for the subclass that would
> handle a given message, then you could easily add a fresh
> subsubclass e.g.
> AddNameSpaceChange subclass: #AddJNINameSpaceChange.
> I suggest this instead of creating a variable since I think the
> problem is naturally static - a give code load has a fixed solution.
>

How would the RTP deal with these subclasses? I fear they would get
stripped out of the image if no special consideration is given to them.

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc