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;








2















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 [ "???" ]
]









share|improve this question

















  • 1





    You could just call the asString selector from asDescription: 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

















2















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 [ "???" ]
]









share|improve this question

















  • 1





    You could just call the asString selector from asDescription: 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













2












2








2








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 [ "???" ]
]









share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Mar 24 at 9:34









adiusadius

6,38542638




6,38542638







  • 1





    You could just call the asString selector from asDescription: 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





    You could just call the asString selector from asDescription: 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












2 Answers
2






active

oldest

votes


















5














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



  1. Files (instances of FileStream)

  2. Sockets (instances of SocketStream)

  3. 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!






share|improve this answer

























  • 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





    @adius Read the Addendum for some more thoughts on this.

    – Leandro Caniglia
    Mar 30 at 10:58


















2














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.






share|improve this answer

























  • 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












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
);



);













draft saved

draft discarded


















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









5














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



  1. Files (instances of FileStream)

  2. Sockets (instances of SocketStream)

  3. 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!






share|improve this answer

























  • 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





    @adius Read the Addendum for some more thoughts on this.

    – Leandro Caniglia
    Mar 30 at 10:58















5














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



  1. Files (instances of FileStream)

  2. Sockets (instances of SocketStream)

  3. 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!






share|improve this answer

























  • 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





    @adius Read the Addendum for some more thoughts on this.

    – Leandro Caniglia
    Mar 30 at 10:58













5












5








5







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



  1. Files (instances of FileStream)

  2. Sockets (instances of SocketStream)

  3. 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!






share|improve this answer















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



  1. Files (instances of FileStream)

  2. Sockets (instances of SocketStream)

  3. 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!







share|improve this answer














share|improve this answer



share|improve this answer








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 implemented printOn in terms of asString. 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






  • 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













2














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.






share|improve this answer

























  • 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
















2














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.






share|improve this answer

























  • 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














2












2








2







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








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


















  • 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


















draft saved

draft discarded
















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

SQL error code 1064 with creating Laravel foreign keysForeign key constraints: When to use ON UPDATE and ON DELETEDropping column with foreign key Laravel error: General error: 1025 Error on renameLaravel SQL Can't create tableLaravel Migration foreign key errorLaravel php artisan migrate:refresh giving a syntax errorSQLSTATE[42S01]: Base table or view already exists or Base table or view already exists: 1050 Tableerror in migrating laravel file to xampp serverSyntax error or access violation: 1064:syntax to use near 'unsigned not null, modelName varchar(191) not null, title varchar(191) not nLaravel cannot create new table field in mysqlLaravel 5.7:Last migration creates table but is not registered in the migration table

용인 삼성생명 블루밍스 목차 통계 역대 감독 선수단 응원단 경기장 같이 보기 외부 링크 둘러보기 메뉴samsungblueminx.comeh선수 명단용인 삼성생명 블루밍스용인 삼성생명 블루밍스ehsamsungblueminx.comeheheheh

155 수학 과학 기타 둘러보기 메뉴eh추가해eh문서를 완성해