Smalltalk › Redline Smalltalk

Runtime Class creation package scope

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Les Hazlewood

Runtime Class creation package scope

Hi James, et. al.

When adding the subclass: binary message selector to the Class class,
I noticed something in my test case:

| class |

class := Class subclass: #Foo

If you then do the following:

Transcript show: class fullyQualifiedName.

You'll see:

st.redline.core.Foo

The test assertion is here:
https://github.com/lhazlewood/redline-smalltalk/blob/767327316b4c0300a7ef711ef2d19b58f73d13af/src/test/smalltalk/st/redline/core/ClassTest.st#L12

I'm assuming that the dynamically created Foo class is automatically
placed in the st.redline.core package because the object that created
it (a st.redline.core.ClassTest instance) is also in that same
package.

Is this desirable? My first expectation is that because I didn't
specify a package name that my dynamically created subclass would be
in the root (empty) package.

What is the reasoning behind the current default behavior? Groovy for
example does not behave this way (it behaves per what I expected -
dynamically created classes that don't specify a package do not have a
package).

Thanks for any clarification,

Les

James Ladd

Re: Runtime Class creation package scope

That is a bug. Please can you raise it as an issue in github?

On Sat, Dec 29, 2012 at 12:45 PM, Les Hazlewood <[hidden email]> wrote:

Hi James, et. al.

When adding the subclass: binary message selector to the Class class,
I noticed something in my test case:

| class |

class := Class subclass: #Foo

If you then do the following:

Transcript show: class fullyQualifiedName.

You'll see:

st.redline.core.Foo

The test assertion is here:
https://github.com/lhazlewood/redline-smalltalk/blob/767327316b4c0300a7ef711ef2d19b58f73d13af/src/test/smalltalk/st/redline/core/ClassTest.st#L12

I'm assuming that the dynamically created Foo class is automatically
placed in the st.redline.core package because the object that created
it (a st.redline.core.ClassTest instance) is also in that same
package.

Is this desirable? My first expectation is that because I didn't
specify a package name that my dynamically created subclass would be
in the root (empty) package.

What is the reasoning behind the current default behavior? Groovy for
example does not behave this way (it behaves per what I expected -
dynamically created classes that don't specify a package do not have a
package).

Thanks for any clarification,

Les

Les Hazlewood

Re: Runtime Class creation package scope

Will do.

On Fri, Dec 28, 2012 at 5:56 PM, James Ladd <[hidden email]> wrote:

> That is a bug. Please can you raise it as an issue in github?
>
>
> On Sat, Dec 29, 2012 at 12:45 PM, Les Hazlewood <[hidden email]> wrote:
>>
>> Hi James, et. al.
>>
>> When adding the subclass: binary message selector to the Class class,
>> I noticed something in my test case:
>>
>> | class |
>>
>> class := Class subclass: #Foo
>>
>> If you then do the following:
>>
>> Transcript show: class fullyQualifiedName.
>>
>> You'll see:
>>
>> st.redline.core.Foo
>>
>> The test assertion is here:
>>
>> https://github.com/lhazlewood/redline-smalltalk/blob/767327316b4c0300a7ef711ef2d19b58f73d13af/src/test/smalltalk/st/redline/core/ClassTest.st#L12
>>
>> I'm assuming that the dynamically created Foo class is automatically
>> placed in the st.redline.core package because the object that created
>> it (a st.redline.core.ClassTest instance) is also in that same
>> package.
>>
>> Is this desirable? My first expectation is that because I didn't
>> specify a package name that my dynamically created subclass would be
>> in the root (empty) package.
>>
>> What is the reasoning behind the current default behavior? Groovy for
>> example does not behave this way (it behaves per what I expected -
>> dynamically created classes that don't specify a package do not have a
>> package).
>>
>> Thanks for any clarification,
>>
>> Les
>
>

James Ladd

Re: Runtime Class creation package scope

I'm making some internal changes that will address that and other issues.

Sent from Hyperspace.

On 29/12/2012, at 5:10 PM, Les Hazlewood <[hidden email]> wrote:

> Will do.
>
> On Fri, Dec 28, 2012 at 5:56 PM, James Ladd <[hidden email]> wrote:
>> That is a bug. Please can you raise it as an issue in github?
>>
>>
>> On Sat, Dec 29, 2012 at 12:45 PM, Les Hazlewood <[hidden email]> wrote:
>>>
>>> Hi James, et. al.
>>>
>>> When adding the subclass: binary message selector to the Class class,
>>> I noticed something in my test case:
>>>
>>> | class |
>>>
>>> class := Class subclass: #Foo
>>>
>>> If you then do the following:
>>>
>>> Transcript show: class fullyQualifiedName.
>>>
>>> You'll see:
>>>
>>> st.redline.core.Foo
>>>
>>> The test assertion is here:
>>>
>>> https://github.com/lhazlewood/redline-smalltalk/blob/767327316b4c0300a7ef711ef2d19b58f73d13af/src/test/smalltalk/st/redline/core/ClassTest.st#L12
>>>
>>> I'm assuming that the dynamically created Foo class is automatically
>>> placed in the st.redline.core package because the object that created
>>> it (a st.redline.core.ClassTest instance) is also in that same
>>> package.
>>>
>>> Is this desirable? My first expectation is that because I didn't
>>> specify a package name that my dynamically created subclass would be
>>> in the root (empty) package.
>>>
>>> What is the reasoning behind the current default behavior? Groovy for
>>> example does not behave this way (it behaves per what I expected -
>>> dynamically created classes that don't specify a package do not have a
>>> package).
>>>
>>> Thanks for any clarification,
>>>
>>> Les
>>
>>

Les Hazlewood

Re: Runtime Class creation package scope

James, two questions based on this:

1. Doesn't this imply that we'll also need to be able to specify the
package name as part of the Class message? For example:

| fooClass |

fooClass := Class subclass: #Foo ... packageName: 'com.whatever.foo'.

2. Could the existing 'category' part of the Class message be used to
satisfy this? e.g.

fooClass := Class subclass: #Foo ... category: 'com.whatever.foo'.

At least as I understand categories in Smalltalk, they are a way of
grouping Classes with related responsibilities. This sounds an awful
lot like a package to me...

But maybe this cause problems for other Smalltalk code... For example,
if I wanted to import Seaside into Redline - Seaside uses the
'category' part of the class creation message. If Redline used that
as a trigger to put those Seaside classes into a package, then things
would fail since all Seaside classes are, at least from a runtime
resolution perspective, all in the same (root/empty) 'package'.

If the answer to #2 is no, then I assume #1 should be yes?

Thoughts?

Les