Smalltalk › Instantiations

A couple of suggestions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Carl Gundel-2

A couple of suggestions

1) When I file in some code and it finds one or more compile errors, it doesn't identify the class(es) in the transcript along with the error. This should be fixed.

2) It doesn't work to have a class side method named comment because this causes the debugger to open when trying to browse changes on a class that has such a method. This should either be fixed, or else there should be a warning when the user tries to compile such a method.

Thanks,

-Carl

--
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/d/optout.

John O'Keefe-3

Re: A couple of suggestions

Carl -

#1 is already fixed for 8.6.1 (case 51665). Here is an example ---

old:

initialize
"RxMatcher initialize"

Cr :=
compiler error "undefined"
--> TextConstants at: #CR.
Lf := TextConstants at: #LF

new:

RxMatcher class>>initialize
"RxMatcher initialize"

Cr :=
compiler error "undefined"
--> TextConstants at: #CR.

For #2, can you explain a bit more about the problem? I have added a class-side comment method to a class and then browsed changes without a debugger appearing. If you can recreate the problem, please open a support case and include the walkback file.

John

On Friday, August 8, 2014 11:45:15 AM UTC-4, Carl Gundel wrote:

1) When I file in some code and it finds one or more compile errors, it doesn't identify the class(es) in the transcript along with the error. This should be fixed.

2) It doesn't work to have a class side method named comment because this causes the debugger to open when trying to browse changes on a class that has such a method. This should either be fixed, or else there should be a warning when the user tries to compile such a method.

Thanks,

-Carl

Carl Gundel-2

Re: A couple of suggestions

John,

Sorry, we have lots of code that we import from VSE, and our classes have comment methods like:

MyClass class methods!

comment

"This class is for thus and such. Use it this way and that. Etc."

So this causes I the problem I described. It also throws an exception if I export the class to a file like so:

MyClass class does not understand notEmpty

The error happens in the last line of EmFileOutInterface>>fileOutSourceOn:from:

fileOutSourceOn: stream from: application

"Write the source for the receiver's methods controlled by application
in chunk format on stream."

^self
  fileOutSourceOn: stream
  from: application
  includingDefinition: true
  includingComment: self getClass comment notEmpty

Thanks,

-Carl

On Tuesday, August 12, 2014 8:21:35 AM UTC-4, John O'Keefe wrote:

Carl -

#1 is already fixed for 8.6.1 (case 51665). Here is an example ---

old:
initialize
"RxMatcher initialize"

Cr :=
compiler error "undefined"
--> TextConstants at: #CR.
Lf := TextConstants at: #LF
new:
RxMatcher class>>initialize
"RxMatcher initialize"

Cr :=
compiler error "undefined"
--> TextConstants at: #CR.

For #2, can you explain a bit more about the problem? I have added a class-side comment method to a class and then browsed changes without a debugger appearing. If you can recreate the problem, please open a support case and include the walkback file.

John

On Friday, August 8, 2014 11:45:15 AM UTC-4, Carl Gundel wrote:
1) When I file in some code and it finds one or more compile errors, it doesn't identify the class(es) in the transcript along with the error. This should be fixed.

2) It doesn't work to have a class side method named comment because this causes the debugger to open when trying to browse changes on a class that has such a method. This should either be fixed, or else there should be a warning when the user tries to compile such a method.

Thanks,

-Carl

Richard Sargent

Re: A couple of suggestions

Administrator

In reply to this post by Carl Gundel-2

On Friday, August 8, 2014 8:45:15 AM UTC-7, Carl Gundel wrote:

2) It doesn't work to have a class side method named comment because this causes the debugger to open when trying to browse changes on a class that has such a method. This should either be fixed, or else there should be a warning when the user tries to compile such a method.

In the Behavior hierarchy, #comment is meant to answer a String. The example you provided showed it answering 'self' (default return). It is not feasible for a Smalltalk vendor to put in guards against application code which violates superclass constraints. The comment method is just one example of such.

You should pre-process the source (either before filing it out from VSE or separately before filing it in). Alternatively, you could subclass the filing-in class and provide your own recognition and handling of a class comment method. You cannot easily override the basic "select text and then select the file-in menu item". However, you can easily invoke your own tool with the file path (or file contents) via you own controlled script.

John O'Keefe-3

Re: A couple of suggestions

Perhaps the VSE Translator should handle this. I'll take a look and see what can be done, but any changes will not be in 8.6.1 (too late in the development cycle).

John

On Tuesday, August 12, 2014 2:40:55 PM UTC-4, Richard Sargent wrote:

On Friday, August 8, 2014 8:45:15 AM UTC-7, Carl Gundel wrote:
2) It doesn't work to have a class side method named comment because this causes the debugger to open when trying to browse changes on a class that has such a method. This should either be fixed, or else there should be a warning when the user tries to compile such a method.

In the Behavior hierarchy, #comment is meant to answer a String. The example you provided showed it answering 'self' (default return). It is not feasible for a Smalltalk vendor to put in guards against application code which violates superclass constraints. The comment method is just one example of such.

You should pre-process the source (either before filing it out from VSE or separately before filing it in). Alternatively, you could subclass the filing-in class and provide your own recognition and handling of a class comment method. You cannot easily override the basic "select text and then select the file-in menu item". However, you can easily invoke your own tool with the file path (or file contents) via you own controlled script.

Carl Gundel-2

Re: A couple of suggestions

In reply to this post by Richard Sargent

Richard,

That's a fine position to take in general, but I suggest that the name comment is probably too generic and that many applications developers would reasonably expect to be able to use that name in their programming.

Just my two cents.

Thanks,

-Carl

On Tuesday, August 12, 2014 2:40:55 PM UTC-4, Richard Sargent wrote:

On Friday, August 8, 2014 8:45:15 AM UTC-7, Carl Gundel wrote:
2) It doesn't work to have a class side method named comment because this causes the debugger to open when trying to browse changes on a class that has such a method. This should either be fixed, or else there should be a warning when the user tries to compile such a method.

In the Behavior hierarchy, #comment is meant to answer a String. The example you provided showed it answering 'self' (default return). It is not feasible for a Smalltalk vendor to put in guards against application code which violates superclass constraints. The comment method is just one example of such.

You should pre-process the source (either before filing it out from VSE or separately before filing it in). Alternatively, you could subclass the filing-in class and provide your own recognition and handling of a class comment method. You cannot easily override the basic "select text and then select the file-in menu item". However, you can easily invoke your own tool with the file path (or file contents) via you own controlled script.

Richard Sargent

Re: A couple of suggestions

Administrator

On Tuesday, August 12, 2014 1:26:29 PM UTC-7, Carl Gundel wrote:

That's a fine position to take in general, but I suggest that the name comment is probably too generic and that many applications developers would reasonably expect to be able to use that name in their programming.

I appreciate your wish here, but it still remains a fact that anyone subclassing existing functionality must take the inherited names into consideration. There are many method names inherited from Object which can cause problems. I have often tripped over code which declares an attribute "error" with corresponding setter and getter methods. Just look in VA and see how many classes have defined functionality that removes this essential behaviour.

The desirability of a name and one's sense of whether it is a good name usually depends heavily on which dialects one is most familiar with. Pharo, GemStone, VW, and VA all define #comment in the Behavior hierarchy. In my experience, I would not expect to use it for meta-behaviour.

Carl Gundel-2

Re: A couple of suggestions

It's only a suggestion. ;-)

On Tuesday, August 12, 2014 4:40:13 PM UTC-4, Richard Sargent wrote:

On Tuesday, August 12, 2014 1:26:29 PM UTC-7, Carl Gundel wrote:
That's a fine position to take in general, but I suggest that the name comment is probably too generic and that many applications developers would reasonably expect to be able to use that name in their programming.

I appreciate your wish here, but it still remains a fact that anyone subclassing existing functionality must take the inherited names into consideration. There are many method names inherited from Object which can cause problems. I have often tripped over code which declares an attribute "error" with corresponding setter and getter methods. Just look in VA and see how many classes have defined functionality that removes this essential behaviour.

The desirability of a name and one's sense of whether it is a good name usually depends heavily on which dialects one is most familiar with. Pharo, GemStone, VW, and VA all define #comment in the Behavior hierarchy. In my experience, I would not expect to use it for meta-behaviour.