Smalltalk › Instantiations

[8.5.2 and 8.6] Text window deficiency for recognizing class names

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Richard Sargent

[8.5.2 and 8.6] Text window deficiency for recognizing class names

Administrator

In most text windows, you can select a class name, right click, and see the option to browse its hierarchy.

But this does not work for qualified class names (app::class). In fact, you cannot even inspect this expression (in the Transcript, at least).

e.g., from the Transcript:
... should not reference GbsRuntime::ISOLatin.

It would be a welcome enhancement.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.

Seth Berman

Re: [8.5.2 and 8.6] Text window deficiency for recognizing class names

Hi Richard,

We took a deeper look at this. This kind of class resolution is not officially supported in the product.

The fact that it can resolve the class in the parser is somewhat anomalous, and may have been preparatory work for true namespace support at one time.

Since Applications are considered managed namespaces it may work, but using this mechanism can lead to some interesting issues once these scope referenced classes are shuffled around to different applications, but the scoped refs (now stale) remain. We would need a lot more tooling and additional unmanaged namespace detection logic in order to really be able to support this.

-- Seth

On Thursday, February 27, 2014 3:06:10 PM UTC-5, Richard Sargent wrote:

In most text windows, you can select a class name, right click, and see the option to browse its hierarchy.

But this does not work for qualified class names (app::class). In fact, you cannot even inspect this expression (in the Transcript, at least).

e.g., from the Transcript:
... should not reference GbsRuntime::ISOLatin.

It would be a welcome enhancement.

Richard Sargent

Re: [8.5.2 and 8.6] Text window deficiency for recognizing class names

Administrator

Thanks, Seth. I would rather see you expend resources to provide a true namespace mechanism (one that allows the same e.g. class name to be used in distinct namespaces).

On Mar 4, 2014 8:40 AM, "Seth Berman" <[hidden email]> wrote:

Hi Richard,

We took a deeper look at this. This kind of class resolution is not officially supported in the product.
The fact that it can resolve the class in the parser is somewhat anomalous, and may have been preparatory work for true namespace support at one time.

Since Applications are considered managed namespaces it may work, but using this mechanism can lead to some interesting issues once these scope referenced classes are shuffled around to different applications, but the scoped refs (now stale) remain. We would need a lot more tooling and additional unmanaged namespace detection logic in order to really be able to support this.

-- Seth

On Thursday, February 27, 2014 3:06:10 PM UTC-5, Richard Sargent wrote:
In most text windows, you can select a class name, right click, and see the option to browse its hierarchy.

But this does not work for qualified class names (app::class). In fact, you cannot even inspect this expression (in the Transcript, at least).

e.g., from the Transcript:
... should not reference GbsRuntime::ISOLatin.

It would be a welcome enhancement.

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/6MbFbhhBP7Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.

Seth Berman

Re: [8.5.2 and 8.6] Text window deficiency for recognizing class names

Hi Richard,

On a very basic level, I concur with you about the value that true namespace support provides.

Out of curiosity, have you listened to the recent James Robertson and David Buck podcast on namespaces. My takeaway was that they deemed it a valuable addition, but that it also introduced some important subtle issues to be aware of. I thought it was interesting.

Namespaces Podcast

-- Seth

On Tuesday, March 4, 2014 11:45:42 AM UTC-5, Richard Sargent wrote:

Thanks, Seth. I would rather see you expend resources to provide a true namespace mechanism (one that allows the same e.g. class name to be used in distinct namespaces).

On Mar 4, 2014 8:40 AM, "Seth Berman" <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="PcVAbRmqWaQJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">sbe...@...> wrote:

Hi Richard,

We took a deeper look at this. This kind of class resolution is not officially supported in the product.
The fact that it can resolve the class in the parser is somewhat anomalous, and may have been preparatory work for true namespace support at one time.

Since Applications are considered managed namespaces it may work, but using this mechanism can lead to some interesting issues once these scope referenced classes are shuffled around to different applications, but the scoped refs (now stale) remain. We would need a lot more tooling and additional unmanaged namespace detection logic in order to really be able to support this.

-- Seth

On Thursday, February 27, 2014 3:06:10 PM UTC-5, Richard Sargent wrote:
In most text windows, you can select a class name, right click, and see the option to browse its hierarchy.

But this does not work for qualified class names (app::class). In fact, you cannot even inspect this expression (in the Transcript, at least).

e.g., from the Transcript:
... should not reference GbsRuntime::ISOLatin.

It would be a welcome enhancement.

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/va-smalltalk/6MbFbhhBP7Q/unsubscribe" target="_blank" onmousedown="this.href='https://groups.google.com/d/topic/va-smalltalk/6MbFbhhBP7Q/unsubscribe';return true;" onclick="this.href='https://groups.google.com/d/topic/va-smalltalk/6MbFbhhBP7Q/unsubscribe';return true;">https://groups.google.com/d/topic/va-smalltalk/6MbFbhhBP7Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="PcVAbRmqWaQJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="PcVAbRmqWaQJ" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">va-sma...@....
Visit this group at <a href="http://groups.google.com/group/va-smalltalk" target="_blank" onmousedown="this.href='http://groups.google.com/group/va-smalltalk';return true;" onclick="this.href='http://groups.google.com/group/va-smalltalk';return true;">http://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank" onmousedown="this.href='https://groups.google.com/groups/opt_out';return true;" onclick="this.href='https://groups.google.com/groups/opt_out';return true;">https://groups.google.com/groups/opt_out.

Richard Sargent

Re: [8.5.2 and 8.6] Text window deficiency for recognizing class names

Administrator

I haven't listened to it, but I shall.

Thanks

On Tuesday, March 4, 2014 9:25:36 AM UTC-8, Seth Berman wrote:

Hi Richard,

On a very basic level, I concur with you about the value that true namespace support provides.
Out of curiosity, have you listened to the recent James Robertson and David Buck podcast on namespaces. My takeaway was that they deemed it a valuable addition, but that it also introduced some important subtle issues to be aware of. I thought it was interesting.
<a href="http://www.jarober.com/blog/blogView?showComments=true&printTitle=IM_163:_Namespaces&entry=3570643110" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.jarober.com%2Fblog%2FblogView%3FshowComments%3Dtrue%26printTitle%3DIM_163%3A_Namespaces%26entry%3D3570643110\46sa\75D\46sntz\0751\46usg\75AFQjCNEbUeucdGmvDFlnDFdgj7JJmVHAcA';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.jarober.com%2Fblog%2FblogView%3FshowComments%3Dtrue%26printTitle%3DIM_163%3A_Namespaces%26entry%3D3570643110\46sa\75D\46sntz\0751\46usg\75AFQjCNEbUeucdGmvDFlnDFdgj7JJmVHAcA';return true;">Namespaces Podcast

-- Seth

On Tuesday, March 4, 2014 11:45:42 AM UTC-5, Richard Sargent wrote:
Thanks, Seth. I would rather see you expend resources to provide a true namespace mechanism (one that allows the same e.g. class name to be used in distinct namespaces).

On Mar 4, 2014 8:40 AM, "Seth Berman" <[hidden email]> wrote:

Hi Richard,

We took a deeper look at this. This kind of class resolution is not officially supported in the product.
The fact that it can resolve the class in the parser is somewhat anomalous, and may have been preparatory work for true namespace support at one time.

Since Applications are considered managed namespaces it may work, but using this mechanism can lead to some interesting issues once these scope referenced classes are shuffled around to different applications, but the scoped refs (now stale) remain. We would need a lot more tooling and additional unmanaged namespace detection logic in order to really be able to support this.

-- Seth

On Thursday, February 27, 2014 3:06:10 PM UTC-5, Richard Sargent wrote:
In most text windows, you can select a class name, right click, and see the option to browse its hierarchy.

But this does not work for qualified class names (app::class). In fact, you cannot even inspect this expression (in the Transcript, at least).

e.g., from the Transcript:
... should not reference GbsRuntime::ISOLatin.

It would be a welcome enhancement.

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/va-smalltalk/6MbFbhhBP7Q/unsubscribe" target="_blank" onmousedown="this.href='https://groups.google.com/d/topic/va-smalltalk/6MbFbhhBP7Q/unsubscribe';return true;" onclick="this.href='https://groups.google.com/d/topic/va-smalltalk/6MbFbhhBP7Q/unsubscribe';return true;">https://groups.google.com/d/topic/va-smalltalk/6MbFbhhBP7Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="http://groups.google.com/group/va-smalltalk" target="_blank" onmousedown="this.href='http://groups.google.com/group/va-smalltalk';return true;" onclick="this.href='http://groups.google.com/group/va-smalltalk';return true;">http://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/groups/opt_out" target="_blank" onmousedown="this.href='https://groups.google.com/groups/opt_out';return true;" onclick="this.href='https://groups.google.com/groups/opt_out';return true;">https://groups.google.com/groups/opt_out.

Richard Sargent

Re: [8.5.2 and 8.6] Text window deficiency for recognizing class names

Administrator

In reply to this post by Seth Berman

On Tuesday, March 4, 2014 8:40:28 AM UTC-8, Seth Berman wrote:

We took a deeper look at this. This kind of class resolution is not officially supported in the product.
The fact that it can resolve the class in the parser is somewhat anomalous, and may have been preparatory work for true namespace support at one time.

I looked further into this as well. The double colon is used frequently (over 1,800 methods in my image), not only in the Abt code but also in a lot of ENVY code, too. There is nothing anomalous about it, in my opinion. e.g., virtually every ("modern") IS_* method uses it.

The parser produces an EsScopedVariableWithBinding to deal with it.

Richard Sargent

Re: [8.5.2 and 8.6] Text window deficiency for recognizing class names

Administrator

In reply to this post by Seth Berman

On Tuesday, March 4, 2014 9:25:36 AM UTC-8, Seth Berman wrote:

On a very basic level, I concur with you about the value that true namespace support provides.
Out of curiosity, have you listened to the recent James Robertson and David Buck podcast on namespaces. My takeaway was that they deemed it a valuable addition, but that it also introduced some important subtle issues to be aware of. I thought it was interesting.
<a href="http://www.jarober.com/blog/blogView?showComments=true&printTitle=IM_163:_Namespaces&entry=3570643110" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.jarober.com%2Fblog%2FblogView%3FshowComments%3Dtrue%26printTitle%3DIM_163%3A_Namespaces%26entry%3D3570643110\46sa\75D\46sntz\0751\46usg\75AFQjCNEbUeucdGmvDFlnDFdgj7JJmVHAcA';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fwww.jarober.com%2Fblog%2FblogView%3FshowComments%3Dtrue%26printTitle%3DIM_163%3A_Namespaces%26entry%3D3570643110\46sa\75D\46sntz\0751\46usg\75AFQjCNEbUeucdGmvDFlnDFdgj7JJmVHAcA';return true;">Namespaces Podcast

That was interesting. My takeaway, if you will, was that you needn't make it so complicated to be useful. :-)

For example, offer two variations: (1) a method can only reference a class or global visible to its application or prerequisite applications and (2) a legacy mode in which a failure to find a definition from the first rule results in a search of all application namespaces (like today) AND produces a warning message to the Transcript. The above rule can be overridden by use of the double colon to specify the namespace in which the reference will be found. It would be an error to find more than one namespace defining a global in the first rule (probably in either rule); the name would need to be qualified/scoped.

Anyway, it's just something for the features wishlist. :-)

John O'Keefe-3

Re: [8.5.2 and 8.6] Text window deficiency for recognizing class names

In reply to this post by Richard Sargent

Richard -

'anomolous' referred to the fact that double colons work (mostly) in the App::Class construct. The documented (and currently the only intended) use is in App::PoolDictionary constructs.

John

On Monday, March 10, 2014 2:07:29 PM UTC-4, Richard Sargent wrote:

On Tuesday, March 4, 2014 8:40:28 AM UTC-8, Seth Berman wrote:
We took a deeper look at this. This kind of class resolution is not officially supported in the product.
The fact that it can resolve the class in the parser is somewhat anomalous, and may have been preparatory work for true namespace support at one time.

I looked further into this as well. The double colon is used frequently (over 1,800 methods in my image), not only in the Abt code but also in a lot of ENVY code, too. There is nothing anomalous about it, in my opinion. e.g., virtually every ("modern") IS_* method uses it.

The parser produces an EsScopedVariableWithBinding to deal with it.