How to add same method with 2 different names in GNU Smalltalk?Images or files in GNU Smalltalk?GNU Smalltalk: Problem with Example in Tutorial (Object creation)Why GNU Smalltalk uses brackets for method bodies?Developing UI's in GNU/SmalltalkHow to subclass OrderedCollection in GNU Smalltalk?How to run GUI related code in GNU Smalltalk?Can not call “function” in GNU SmalltalkRefactoring methods and creating copies with a different name in Pharo Smalltalk?Understanding GNU Smalltalk ClosureHow to just get key only on GNU Smalltalk?
In what episode of TOS did a character on the bridge make a comment about raising the number 1 to some power?
Draw a checker pattern with a black X in the center
What are the benefits of cryosleep?
Why do Russians call their women expensive ("дорогая")?
Yandex programming contest: Alarms
Writing the notation when gates act on non successive registers
What does "tea juice" mean in this context?
Mapping a function f[xi_,xj_] over a list x1, ...., xn with the i < j restriction
If a massive object like Jupiter flew past the Earth how close would it need to come to pull people off of the surface?
Could IPv6 make NAT / port numbers redundant?
What are the problems in teaching guitar via Skype?
Biblical Basis for 400 years of silence between old and new testament
Restoring order in a deck of playing cards
Can you move on your turn, and then use the Ready Action to move again on another creature's turn?
How can I grammatically understand "Wir über uns"?
Uncommanded roll at high speed
How to capture more stars?
Can an old DSLR be upgraded to match modern smartphone image quality
Is there an explanation for Austria's Freedom Party virtually retaining its vote share despite recent scandal?
How do I subvert the tropes of a train heist?
What kind of appearance can I expect if I both overexpose and push film?
The qvolume of an integer
Modern approach to radio buttons
Mark as deprecated function parameters in C++14
How to add same method with 2 different names in GNU Smalltalk?
Images or files in GNU Smalltalk?GNU Smalltalk: Problem with Example in Tutorial (Object creation)Why GNU Smalltalk uses brackets for method bodies?Developing UI's in GNU/SmalltalkHow to subclass OrderedCollection in GNU Smalltalk?How to run GUI related code in GNU Smalltalk?Can not call “function” in GNU SmalltalkRefactoring methods and creating copies with a different name in Pharo Smalltalk?Understanding GNU Smalltalk ClosureHow to just get key only on GNU Smalltalk?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
How can I have a class expose the same method with 2 different names?
E.g. that the asDescripton function does the same thing / re-exports the asString function without simply copy-pasting the code.
Object subclass: Element [
| width height |
Element class >> new [
^super new init.
]
init [
width := 0.
height := 0.
]
asString [
^ 'Element with width ', width, ' and height ', height.
]
asDescription [ "???" ]
]
smalltalk gnu-smalltalk
add a comment |
How can I have a class expose the same method with 2 different names?
E.g. that the asDescripton function does the same thing / re-exports the asString function without simply copy-pasting the code.
Object subclass: Element [
| width height |
Element class >> new [
^super new init.
]
init [
width := 0.
height := 0.
]
asString [
^ 'Element with width ', width, ' and height ', height.
]
asDescription [ "???" ]
]
smalltalk gnu-smalltalk
1
You could just call theasStringselector fromasDescription:asDescription [ ^ asString ].
– lurker
Mar 24 at 9:36
1
Please accept the answer when it suits your needs - stackoverflow.com/help/someone-answers
– tukan
Apr 1 at 18:26
add a comment |
How can I have a class expose the same method with 2 different names?
E.g. that the asDescripton function does the same thing / re-exports the asString function without simply copy-pasting the code.
Object subclass: Element [
| width height |
Element class >> new [
^super new init.
]
init [
width := 0.
height := 0.
]
asString [
^ 'Element with width ', width, ' and height ', height.
]
asDescription [ "???" ]
]
smalltalk gnu-smalltalk
How can I have a class expose the same method with 2 different names?
E.g. that the asDescripton function does the same thing / re-exports the asString function without simply copy-pasting the code.
Object subclass: Element [
| width height |
Element class >> new [
^super new init.
]
init [
width := 0.
height := 0.
]
asString [
^ 'Element with width ', width, ' and height ', height.
]
asDescription [ "???" ]
]
smalltalk gnu-smalltalk
smalltalk gnu-smalltalk
asked Mar 24 at 9:34
adiusadius
6,38542638
6,38542638
1
You could just call theasStringselector fromasDescription:asDescription [ ^ asString ].
– lurker
Mar 24 at 9:36
1
Please accept the answer when it suits your needs - stackoverflow.com/help/someone-answers
– tukan
Apr 1 at 18:26
add a comment |
1
You could just call theasStringselector fromasDescription:asDescription [ ^ asString ].
– lurker
Mar 24 at 9:36
1
Please accept the answer when it suits your needs - stackoverflow.com/help/someone-answers
– tukan
Apr 1 at 18:26
1
1
You could just call the
asString selector from asDescription: asDescription [ ^ asString ].– lurker
Mar 24 at 9:36
You could just call the
asString selector from asDescription: asDescription [ ^ asString ].– lurker
Mar 24 at 9:36
1
1
Please accept the answer when it suits your needs - stackoverflow.com/help/someone-answers
– tukan
Apr 1 at 18:26
Please accept the answer when it suits your needs - stackoverflow.com/help/someone-answers
– tukan
Apr 1 at 18:26
add a comment |
2 Answers
2
active
oldest
votes
In Smalltalk you usually implement #printOn: and get #asString from the inherited version of it which goes on the lines of
Object >> asString
| stream |
stream := '' writeStream.
self printOn: stream.
^stream contents
The actual implementation of this method may be slightly different in your environment, the idea remains the same.
As this is given, it is usually a good idea to implement #printOn: rather than #asString. In your case you would have it implemented as
Element >> printOn: aStream
aStream
nextPutAll: 'Element with width ';
nextPutAll: width asString;
nextPutAll: ' and height ';
nextPutAll: height asString
and then, as JayK and luker indicated,
Element >> asDescription
^self asString
In other words, you (usually) don't want to implement #asString but #printOn:. This approach is better because it takes advantage of the inheritance and ensures consistency between #printOn: and #asString, which is usually expected. In addition, it will give you the opportunity to start becoming familiar with Streams, which play a central role in Smalltalk.
Note by the way that in my implementation I've used width asString and heigh asString. Your code attempts to concatenate (twice) a String with a Number:
'Element with width ', width, ' and height ', height.
which won't work as you can only concatenate instances of String with #,.
In most of the dialects, however, you can avoid sending #asString by using #print: instead of #nextPutAll:, something like:
Element >> printOn: aStream
aStream
nextPutAll: 'Element with width ';
print: width;
nextPutAll: ' and height ';
print: height
which is a little bit less verbose and therefore preferred.
One last thing. I would recommend changing the first line above with this one:
nextPutAll: self class name;
nextPutAll: ' with width ';
instead of hardcoding the class name. This would prove to be useful if in the future you subclass Element because you will have no need to tweak #printOn: and any of its derivatives (e.g., #asDescription).
Final thought: I would rename the selector #asDescription to be #description. The preposition as is intended to convert an object to another of a different class (this is why #asString is ok). But this doesn't seem to be the case here.
Addendum: Why?
There is a reason why #asString is implemented in terms of #printOn:, and not the other way around: generality. While the effort (code complexity) is the same, #printOn: is clearly a winner because it will work with any character Stream. In particular, it will work with no modification whatsoever with
- Files (instances of
FileStream) - Sockets (instances of
SocketStream) - The
Transcript
In other words, by implementing #printOn: one gets #asString for free (inheritance) and --at the same time-- the ability to dump a representation of the object on files and sockets. The Transcript is particularly interesting because it supports the Stream protocol for writing, and thus can be used for testing purposes before sending any bytes to external devices.
Remember!
In Smalltalk, the goal is to have objects whose behavior is simple and general at once, not just simple!
Oh interesting. I was doing it actually the other way round: I implementedprintOnin terms ofasString. Felt more natural coming from a Haskell background.
– adius
Mar 30 at 9:43
1
@adius Read the Addendum for some more thoughts on this.
– Leandro Caniglia
Mar 30 at 10:58
add a comment |
As lurker wrote in the comments, send the asString message in asDescription.
asDescription
^ self asString
This is usually done to expose additional interfaces/protocols from a class, for compatibility or as a built-in adapter. If you create something new that does not have to fit in anywhere else, consider to stick to just one name for each operation.
Edit: if you really are after the re-export semantics and do not want the additional message sends involved in the delegation above, there might be a way to put the CompiledMethod of asString in the method dictionary of the class a second time under the other name. But neither am I sure that this would work, nor do I know the protocol in GNU Smalltalk how to manipulate the method dictionary. Have a look at the documentation of the Behavior class. Also, I would not consider this as programming Smalltalk, but tinkering with the system.
I think that CompiledMethod retains a pointer to method selector in st80 and descendants. it's mostly for decompiling or retrieving source code (in a debugger), but maybe there is another use that I missed. So I can't tell if there would be a side effect of sharing same compiledMethod in two different selector entries in methodDictionary. Worth a try...
– aka.nice
Mar 24 at 22:12
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55322402%2fhow-to-add-same-method-with-2-different-names-in-gnu-smalltalk%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
In Smalltalk you usually implement #printOn: and get #asString from the inherited version of it which goes on the lines of
Object >> asString
| stream |
stream := '' writeStream.
self printOn: stream.
^stream contents
The actual implementation of this method may be slightly different in your environment, the idea remains the same.
As this is given, it is usually a good idea to implement #printOn: rather than #asString. In your case you would have it implemented as
Element >> printOn: aStream
aStream
nextPutAll: 'Element with width ';
nextPutAll: width asString;
nextPutAll: ' and height ';
nextPutAll: height asString
and then, as JayK and luker indicated,
Element >> asDescription
^self asString
In other words, you (usually) don't want to implement #asString but #printOn:. This approach is better because it takes advantage of the inheritance and ensures consistency between #printOn: and #asString, which is usually expected. In addition, it will give you the opportunity to start becoming familiar with Streams, which play a central role in Smalltalk.
Note by the way that in my implementation I've used width asString and heigh asString. Your code attempts to concatenate (twice) a String with a Number:
'Element with width ', width, ' and height ', height.
which won't work as you can only concatenate instances of String with #,.
In most of the dialects, however, you can avoid sending #asString by using #print: instead of #nextPutAll:, something like:
Element >> printOn: aStream
aStream
nextPutAll: 'Element with width ';
print: width;
nextPutAll: ' and height ';
print: height
which is a little bit less verbose and therefore preferred.
One last thing. I would recommend changing the first line above with this one:
nextPutAll: self class name;
nextPutAll: ' with width ';
instead of hardcoding the class name. This would prove to be useful if in the future you subclass Element because you will have no need to tweak #printOn: and any of its derivatives (e.g., #asDescription).
Final thought: I would rename the selector #asDescription to be #description. The preposition as is intended to convert an object to another of a different class (this is why #asString is ok). But this doesn't seem to be the case here.
Addendum: Why?
There is a reason why #asString is implemented in terms of #printOn:, and not the other way around: generality. While the effort (code complexity) is the same, #printOn: is clearly a winner because it will work with any character Stream. In particular, it will work with no modification whatsoever with
- Files (instances of
FileStream) - Sockets (instances of
SocketStream) - The
Transcript
In other words, by implementing #printOn: one gets #asString for free (inheritance) and --at the same time-- the ability to dump a representation of the object on files and sockets. The Transcript is particularly interesting because it supports the Stream protocol for writing, and thus can be used for testing purposes before sending any bytes to external devices.
Remember!
In Smalltalk, the goal is to have objects whose behavior is simple and general at once, not just simple!
Oh interesting. I was doing it actually the other way round: I implementedprintOnin terms ofasString. Felt more natural coming from a Haskell background.
– adius
Mar 30 at 9:43
1
@adius Read the Addendum for some more thoughts on this.
– Leandro Caniglia
Mar 30 at 10:58
add a comment |
In Smalltalk you usually implement #printOn: and get #asString from the inherited version of it which goes on the lines of
Object >> asString
| stream |
stream := '' writeStream.
self printOn: stream.
^stream contents
The actual implementation of this method may be slightly different in your environment, the idea remains the same.
As this is given, it is usually a good idea to implement #printOn: rather than #asString. In your case you would have it implemented as
Element >> printOn: aStream
aStream
nextPutAll: 'Element with width ';
nextPutAll: width asString;
nextPutAll: ' and height ';
nextPutAll: height asString
and then, as JayK and luker indicated,
Element >> asDescription
^self asString
In other words, you (usually) don't want to implement #asString but #printOn:. This approach is better because it takes advantage of the inheritance and ensures consistency between #printOn: and #asString, which is usually expected. In addition, it will give you the opportunity to start becoming familiar with Streams, which play a central role in Smalltalk.
Note by the way that in my implementation I've used width asString and heigh asString. Your code attempts to concatenate (twice) a String with a Number:
'Element with width ', width, ' and height ', height.
which won't work as you can only concatenate instances of String with #,.
In most of the dialects, however, you can avoid sending #asString by using #print: instead of #nextPutAll:, something like:
Element >> printOn: aStream
aStream
nextPutAll: 'Element with width ';
print: width;
nextPutAll: ' and height ';
print: height
which is a little bit less verbose and therefore preferred.
One last thing. I would recommend changing the first line above with this one:
nextPutAll: self class name;
nextPutAll: ' with width ';
instead of hardcoding the class name. This would prove to be useful if in the future you subclass Element because you will have no need to tweak #printOn: and any of its derivatives (e.g., #asDescription).
Final thought: I would rename the selector #asDescription to be #description. The preposition as is intended to convert an object to another of a different class (this is why #asString is ok). But this doesn't seem to be the case here.
Addendum: Why?
There is a reason why #asString is implemented in terms of #printOn:, and not the other way around: generality. While the effort (code complexity) is the same, #printOn: is clearly a winner because it will work with any character Stream. In particular, it will work with no modification whatsoever with
- Files (instances of
FileStream) - Sockets (instances of
SocketStream) - The
Transcript
In other words, by implementing #printOn: one gets #asString for free (inheritance) and --at the same time-- the ability to dump a representation of the object on files and sockets. The Transcript is particularly interesting because it supports the Stream protocol for writing, and thus can be used for testing purposes before sending any bytes to external devices.
Remember!
In Smalltalk, the goal is to have objects whose behavior is simple and general at once, not just simple!
Oh interesting. I was doing it actually the other way round: I implementedprintOnin terms ofasString. Felt more natural coming from a Haskell background.
– adius
Mar 30 at 9:43
1
@adius Read the Addendum for some more thoughts on this.
– Leandro Caniglia
Mar 30 at 10:58
add a comment |
In Smalltalk you usually implement #printOn: and get #asString from the inherited version of it which goes on the lines of
Object >> asString
| stream |
stream := '' writeStream.
self printOn: stream.
^stream contents
The actual implementation of this method may be slightly different in your environment, the idea remains the same.
As this is given, it is usually a good idea to implement #printOn: rather than #asString. In your case you would have it implemented as
Element >> printOn: aStream
aStream
nextPutAll: 'Element with width ';
nextPutAll: width asString;
nextPutAll: ' and height ';
nextPutAll: height asString
and then, as JayK and luker indicated,
Element >> asDescription
^self asString
In other words, you (usually) don't want to implement #asString but #printOn:. This approach is better because it takes advantage of the inheritance and ensures consistency between #printOn: and #asString, which is usually expected. In addition, it will give you the opportunity to start becoming familiar with Streams, which play a central role in Smalltalk.
Note by the way that in my implementation I've used width asString and heigh asString. Your code attempts to concatenate (twice) a String with a Number:
'Element with width ', width, ' and height ', height.
which won't work as you can only concatenate instances of String with #,.
In most of the dialects, however, you can avoid sending #asString by using #print: instead of #nextPutAll:, something like:
Element >> printOn: aStream
aStream
nextPutAll: 'Element with width ';
print: width;
nextPutAll: ' and height ';
print: height
which is a little bit less verbose and therefore preferred.
One last thing. I would recommend changing the first line above with this one:
nextPutAll: self class name;
nextPutAll: ' with width ';
instead of hardcoding the class name. This would prove to be useful if in the future you subclass Element because you will have no need to tweak #printOn: and any of its derivatives (e.g., #asDescription).
Final thought: I would rename the selector #asDescription to be #description. The preposition as is intended to convert an object to another of a different class (this is why #asString is ok). But this doesn't seem to be the case here.
Addendum: Why?
There is a reason why #asString is implemented in terms of #printOn:, and not the other way around: generality. While the effort (code complexity) is the same, #printOn: is clearly a winner because it will work with any character Stream. In particular, it will work with no modification whatsoever with
- Files (instances of
FileStream) - Sockets (instances of
SocketStream) - The
Transcript
In other words, by implementing #printOn: one gets #asString for free (inheritance) and --at the same time-- the ability to dump a representation of the object on files and sockets. The Transcript is particularly interesting because it supports the Stream protocol for writing, and thus can be used for testing purposes before sending any bytes to external devices.
Remember!
In Smalltalk, the goal is to have objects whose behavior is simple and general at once, not just simple!
In Smalltalk you usually implement #printOn: and get #asString from the inherited version of it which goes on the lines of
Object >> asString
| stream |
stream := '' writeStream.
self printOn: stream.
^stream contents
The actual implementation of this method may be slightly different in your environment, the idea remains the same.
As this is given, it is usually a good idea to implement #printOn: rather than #asString. In your case you would have it implemented as
Element >> printOn: aStream
aStream
nextPutAll: 'Element with width ';
nextPutAll: width asString;
nextPutAll: ' and height ';
nextPutAll: height asString
and then, as JayK and luker indicated,
Element >> asDescription
^self asString
In other words, you (usually) don't want to implement #asString but #printOn:. This approach is better because it takes advantage of the inheritance and ensures consistency between #printOn: and #asString, which is usually expected. In addition, it will give you the opportunity to start becoming familiar with Streams, which play a central role in Smalltalk.
Note by the way that in my implementation I've used width asString and heigh asString. Your code attempts to concatenate (twice) a String with a Number:
'Element with width ', width, ' and height ', height.
which won't work as you can only concatenate instances of String with #,.
In most of the dialects, however, you can avoid sending #asString by using #print: instead of #nextPutAll:, something like:
Element >> printOn: aStream
aStream
nextPutAll: 'Element with width ';
print: width;
nextPutAll: ' and height ';
print: height
which is a little bit less verbose and therefore preferred.
One last thing. I would recommend changing the first line above with this one:
nextPutAll: self class name;
nextPutAll: ' with width ';
instead of hardcoding the class name. This would prove to be useful if in the future you subclass Element because you will have no need to tweak #printOn: and any of its derivatives (e.g., #asDescription).
Final thought: I would rename the selector #asDescription to be #description. The preposition as is intended to convert an object to another of a different class (this is why #asString is ok). But this doesn't seem to be the case here.
Addendum: Why?
There is a reason why #asString is implemented in terms of #printOn:, and not the other way around: generality. While the effort (code complexity) is the same, #printOn: is clearly a winner because it will work with any character Stream. In particular, it will work with no modification whatsoever with
- Files (instances of
FileStream) - Sockets (instances of
SocketStream) - The
Transcript
In other words, by implementing #printOn: one gets #asString for free (inheritance) and --at the same time-- the ability to dump a representation of the object on files and sockets. The Transcript is particularly interesting because it supports the Stream protocol for writing, and thus can be used for testing purposes before sending any bytes to external devices.
Remember!
In Smalltalk, the goal is to have objects whose behavior is simple and general at once, not just simple!
edited Mar 30 at 10:57
answered Mar 24 at 12:43
Leandro CanigliaLeandro Caniglia
9,68122137
9,68122137
Oh interesting. I was doing it actually the other way round: I implementedprintOnin terms ofasString. Felt more natural coming from a Haskell background.
– adius
Mar 30 at 9:43
1
@adius Read the Addendum for some more thoughts on this.
– Leandro Caniglia
Mar 30 at 10:58
add a comment |
Oh interesting. I was doing it actually the other way round: I implementedprintOnin terms ofasString. Felt more natural coming from a Haskell background.
– adius
Mar 30 at 9:43
1
@adius Read the Addendum for some more thoughts on this.
– Leandro Caniglia
Mar 30 at 10:58
Oh interesting. I was doing it actually the other way round: I implemented
printOn in terms of asString. Felt more natural coming from a Haskell background.– adius
Mar 30 at 9:43
Oh interesting. I was doing it actually the other way round: I implemented
printOn in terms of asString. Felt more natural coming from a Haskell background.– adius
Mar 30 at 9:43
1
1
@adius Read the Addendum for some more thoughts on this.
– Leandro Caniglia
Mar 30 at 10:58
@adius Read the Addendum for some more thoughts on this.
– Leandro Caniglia
Mar 30 at 10:58
add a comment |
As lurker wrote in the comments, send the asString message in asDescription.
asDescription
^ self asString
This is usually done to expose additional interfaces/protocols from a class, for compatibility or as a built-in adapter. If you create something new that does not have to fit in anywhere else, consider to stick to just one name for each operation.
Edit: if you really are after the re-export semantics and do not want the additional message sends involved in the delegation above, there might be a way to put the CompiledMethod of asString in the method dictionary of the class a second time under the other name. But neither am I sure that this would work, nor do I know the protocol in GNU Smalltalk how to manipulate the method dictionary. Have a look at the documentation of the Behavior class. Also, I would not consider this as programming Smalltalk, but tinkering with the system.
I think that CompiledMethod retains a pointer to method selector in st80 and descendants. it's mostly for decompiling or retrieving source code (in a debugger), but maybe there is another use that I missed. So I can't tell if there would be a side effect of sharing same compiledMethod in two different selector entries in methodDictionary. Worth a try...
– aka.nice
Mar 24 at 22:12
add a comment |
As lurker wrote in the comments, send the asString message in asDescription.
asDescription
^ self asString
This is usually done to expose additional interfaces/protocols from a class, for compatibility or as a built-in adapter. If you create something new that does not have to fit in anywhere else, consider to stick to just one name for each operation.
Edit: if you really are after the re-export semantics and do not want the additional message sends involved in the delegation above, there might be a way to put the CompiledMethod of asString in the method dictionary of the class a second time under the other name. But neither am I sure that this would work, nor do I know the protocol in GNU Smalltalk how to manipulate the method dictionary. Have a look at the documentation of the Behavior class. Also, I would not consider this as programming Smalltalk, but tinkering with the system.
I think that CompiledMethod retains a pointer to method selector in st80 and descendants. it's mostly for decompiling or retrieving source code (in a debugger), but maybe there is another use that I missed. So I can't tell if there would be a side effect of sharing same compiledMethod in two different selector entries in methodDictionary. Worth a try...
– aka.nice
Mar 24 at 22:12
add a comment |
As lurker wrote in the comments, send the asString message in asDescription.
asDescription
^ self asString
This is usually done to expose additional interfaces/protocols from a class, for compatibility or as a built-in adapter. If you create something new that does not have to fit in anywhere else, consider to stick to just one name for each operation.
Edit: if you really are after the re-export semantics and do not want the additional message sends involved in the delegation above, there might be a way to put the CompiledMethod of asString in the method dictionary of the class a second time under the other name. But neither am I sure that this would work, nor do I know the protocol in GNU Smalltalk how to manipulate the method dictionary. Have a look at the documentation of the Behavior class. Also, I would not consider this as programming Smalltalk, but tinkering with the system.
As lurker wrote in the comments, send the asString message in asDescription.
asDescription
^ self asString
This is usually done to expose additional interfaces/protocols from a class, for compatibility or as a built-in adapter. If you create something new that does not have to fit in anywhere else, consider to stick to just one name for each operation.
Edit: if you really are after the re-export semantics and do not want the additional message sends involved in the delegation above, there might be a way to put the CompiledMethod of asString in the method dictionary of the class a second time under the other name. But neither am I sure that this would work, nor do I know the protocol in GNU Smalltalk how to manipulate the method dictionary. Have a look at the documentation of the Behavior class. Also, I would not consider this as programming Smalltalk, but tinkering with the system.
edited Mar 24 at 10:45
answered Mar 24 at 10:37
JayKJayK
1,56611119
1,56611119
I think that CompiledMethod retains a pointer to method selector in st80 and descendants. it's mostly for decompiling or retrieving source code (in a debugger), but maybe there is another use that I missed. So I can't tell if there would be a side effect of sharing same compiledMethod in two different selector entries in methodDictionary. Worth a try...
– aka.nice
Mar 24 at 22:12
add a comment |
I think that CompiledMethod retains a pointer to method selector in st80 and descendants. it's mostly for decompiling or retrieving source code (in a debugger), but maybe there is another use that I missed. So I can't tell if there would be a side effect of sharing same compiledMethod in two different selector entries in methodDictionary. Worth a try...
– aka.nice
Mar 24 at 22:12
I think that CompiledMethod retains a pointer to method selector in st80 and descendants. it's mostly for decompiling or retrieving source code (in a debugger), but maybe there is another use that I missed. So I can't tell if there would be a side effect of sharing same compiledMethod in two different selector entries in methodDictionary. Worth a try...
– aka.nice
Mar 24 at 22:12
I think that CompiledMethod retains a pointer to method selector in st80 and descendants. it's mostly for decompiling or retrieving source code (in a debugger), but maybe there is another use that I missed. So I can't tell if there would be a side effect of sharing same compiledMethod in two different selector entries in methodDictionary. Worth a try...
– aka.nice
Mar 24 at 22:12
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55322402%2fhow-to-add-same-method-with-2-different-names-in-gnu-smalltalk%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
You could just call the
asStringselector fromasDescription:asDescription [ ^ asString ].– lurker
Mar 24 at 9:36
1
Please accept the answer when it suits your needs - stackoverflow.com/help/someone-answers
– tukan
Apr 1 at 18:26