The Trunk: Graphics-mt.430.mcz
Locked
 
|
Marcel Taeumel uploaded a new version of Graphics to project The Trunk:
http://source.squeak.org/trunk/Graphics-mt.430.mcz ==================== Summary ==================== Name: Graphics-mt.430 Author: mt Time: 17 April 2020, 4:52:36.27086 pm UUID: 1e5eac6b-e758-8445-b60e-7b09db8dcc63 Ancestors: Graphics-nice.429 Adds a simple way to use forms as text anchors without exposing Morphic, where such anchors are currently implemented. =============== Diff against Graphics-nice.429 =============== Item was added: + ----- Method: Form>>asTextAnchor (in category 'converting') ----- + asTextAnchor + "Convert the receiver to be embedded in text." + + self flag: #refactor. "mt: Text anchors should work outside of Morphic, too. Any instance of Form could be embedded in Text." + ^ (Smalltalk classNamed: 'TextAnchor') + ifNil: [TextColor black "Fall back"] + ifNotNil: [:cls | cls new anchoredMorph: self]! |
Re: The Trunk: Graphics-mt.430.mcz
|
|
> + ifNil: [TextColor black "Fall back"] Do you think there would be the need for an explicit FallbackTextAttribute, which acts like a null object?
Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]>
Gesendet: Freitag, 17. April 2020 16:52:44 An: [hidden email]; [hidden email] Betreff: [squeak-dev] The Trunk: Graphics-mt.430.mcz Marcel Taeumel uploaded a new version of Graphics to project The Trunk:
http://source.squeak.org/trunk/Graphics-mt.430.mcz ==================== Summary ==================== Name: Graphics-mt.430 Author: mt Time: 17 April 2020, 4:52:36.27086 pm UUID: 1e5eac6b-e758-8445-b60e-7b09db8dcc63 Ancestors: Graphics-nice.429 Adds a simple way to use forms as text anchors without exposing Morphic, where such anchors are currently implemented. =============== Diff against Graphics-nice.429 =============== Item was added: + ----- Method: Form>>asTextAnchor (in category 'converting') ----- + asTextAnchor + "Convert the receiver to be embedded in text." + + self flag: #refactor. "mt: Text anchors should work outside of Morphic, too. Any instance of Form could be embedded in Text." + ^ (Smalltalk classNamed: 'TextAnchor') + ifNil: [TextColor black "Fall back"] + ifNotNil: [:cls | cls new anchoredMorph: self]!
Carpe Squeak!
|
Re: The Trunk: Graphics-mt.430.mcz
|
|
> On 18.04.2020, at 15:37, Thiede, Christoph <[hidden email]> wrote: > > > + ifNil: [TextColor black "Fall back"] > > Do you think there would be the need for an explicit FallbackTextAttribute, which acts like a null object? That's essentially what it is. No need to overengineer. Best regards -Tobias > Von: Squeak-dev <[hidden email]> im Auftrag von [hidden email] <[hidden email]> > Gesendet: Freitag, 17. April 2020 16:52:44 > An: [hidden email]; [hidden email] > Betreff: [squeak-dev] The Trunk: Graphics-mt.430.mcz > > Marcel Taeumel uploaded a new version of Graphics to project The Trunk: > http://source.squeak.org/trunk/Graphics-mt.430.mcz > > ==================== Summary ==================== > > Name: Graphics-mt.430 > Author: mt > Time: 17 April 2020, 4:52:36.27086 pm > UUID: 1e5eac6b-e758-8445-b60e-7b09db8dcc63 > Ancestors: Graphics-nice.429 > > Adds a simple way to use forms as text anchors without exposing Morphic, where such anchors are currently implemented. > > =============== Diff against Graphics-nice.429 =============== > > Item was added: > + ----- Method: Form>>asTextAnchor (in category 'converting') ----- > + asTextAnchor > + "Convert the receiver to be embedded in text." > + > + self flag: #refactor. "mt: Text anchors should work outside of Morphic, too. Any instance of Form could be embedded in Text." > + ^ (Smalltalk classNamed: 'TextAnchor') > + ifNil: [TextColor black "Fall back"] > + ifNotNil: [:cls | cls new anchoredMorph: self]! |
Re: The Trunk: Graphics-mt.430.mcz
|
Agree. In this case, "TextColor black" works as such a "null object" for text attributes. :-) No need to add one for TextAnchor only. Best, Marcel
|
Re: The Trunk: Graphics-mt.430.mcz
|
|
In reply to this post by Tobias Pape
Does it matter if the text is white on black? Note that "Smalltalk classNamed: ..." is not Environments-friendly unless we changed the default binding of #Smalltalk. Also, why not use a Symbol for the class name? The bindings all have Symbols as keys anyway, so you might trigger a conversion on each invocation. Didn't look it up though. Tobias Pape <[hidden email]> schrieb am Sa., 18. Apr. 2020, 16:30:
|
Re: The Trunk: Graphics-mt.430.mcz
|
|
> Note that "Smalltalk classNamed: ..." is not Environments-friendly Good to know! What to use instead? > Also, why not use a Symbol for the class name? Name feels like string. Symbol feels like "key". Best, Marcel
|
Re: The Trunk: Graphics-mt.430.mcz
|
|
Am Di., 21. Apr. 2020 um 12:37 Uhr schrieb Marcel Taeumel
<[hidden email]>: > > > Note that "Smalltalk classNamed: ..." is not Environments-friendly > > Good to know! What to use instead? > 1. If you want to do the lookup in the same environment as the receiver class (like referring to the class directly, but not resolved at compile time): self class environment classNamed: ... 2. If you want to do the lookup in the context-dependent environment (supplied on the stack, cannot be done by referring to the class directly): Environment current classNamed: .... Here, option 1 is probably the way to go. |
Re: The Trunk: Graphics-mt.430.mcz
|
|
In reply to this post by marcel.taeumel
On Tue, Apr 21, 2020 at 5:37 AM Marcel Taeumel <[hidden email]> wrote:
Class and selector names should be symbolic. They're keys to accessing specific objects in the system... |
Re: The Trunk: Graphics-mt.430.mcz
|
|
> Class and selector names should be symbolic. They're keys to accessing specific objects in the system... Sure, but that's the next level of interpretation of the term "name" in the specific class context. Without knowing anything, I would always choose strings over symbols for something that requests a name because names don't have to be identical, they just label stuff. Best, Marcel
|
Re: The Trunk: Graphics-mt.430.mcz
|
|
But you already know that this is a class name (hence classNamed:), not just any name. And the name is complete (not a fragment), so there won't be any waste in the Symbol table. One could only argue whether it is an implementation detail that classes are bound to Symbols and that their names are Symbols. You could ask the same for selectors. Marcel Taeumel <[hidden email]> schrieb am Fr., 24. Apr. 2020, 16:39:
|
Re: The Trunk: Graphics-mt.430.mcz
|
|
> But you already know that this is a class name... That's not the point. I am arguing for simplicity and discoverability. You arguing in favor of some implementation detail for a performance gain. That's not a good path ... ;-) #classNamed: is confusing in this regard. There should be a #classAt: if you want the client to specify an identifier. Best, Marcel
|
Re: The Trunk: Graphics-mt.430.mcz
|
|
In reply to this post by Jakob Reschke
> On 24.04.2020, at 18:41, Jakob Reschke <[hidden email]> wrote: > > But you already know that this is a class name (hence classNamed:), not just any name. And the name is complete (not a fragment), so there won't be any waste in the Symbol table. Do you know that classNamed supports this? Smalltalk classNamed: 'Morph class' Best regards -Tobias > > One could only argue whether it is an implementation detail that classes are bound to Symbols and that their names are Symbols. You could ask the same for selectors. > > Otherwise, I would not write x = 1.0 if I know that x is always an integer (or the other way around). > > > > Marcel Taeumel <[hidden email]> schrieb am Fr., 24. Apr. 2020, 16:39: > > Class and selector names should be symbolic. They're keys to accessing specific objects in the system... > > Sure, but that's the next level of interpretation of the term "name" in the specific class context. Without knowing anything, I would always choose strings over symbols for something that requests a name because names don't have to be identical, they just label stuff. > > Best, > Marcel >> Am 24.04.2020 00:50:50 schrieb Chris Muller <[hidden email]>: >> >> On Tue, Apr 21, 2020 at 5:37 AM Marcel Taeumel <[hidden email]> wrote: >> > Note that "Smalltalk classNamed: ..." is not Environments-friendly >> >> Good to know! What to use instead? >> >> > Also, why not use a Symbol for the class name? >> >> Name feels like string. Symbol feels like "key". >> >> Class and selector names should be symbolic. They're keys to accessing specific objects in the system... >> > > |
Re: The Trunk: Graphics-mt.430.mcz
|
|
In reply to this post by marcel.taeumel
Whoa! After years of arguing that we should be using Dictionary's and #=, instead of IdentityDictionary's and #==, someone pops up even _more_ sympathetic to it than crazy ol'e me, LOL! On Fri, Apr 24, 2020 at 12:08 PM Marcel Taeumel <[hidden email]> wrote:
I'm not. For me, it's the fact that the class names managed by Smalltalk really are known from the outside to be semantically symbolic, distinct and canonical. Like ENUM values. Not "names" of undistinct objects like "Fred" . But, your personal preference, Marcel, is much more palatable to me than the places we employ IdentityDictionary's and #== because we "know" we're using Symbols in underneath.
Yes, but having both is overkill and #classNamed: is too legacy to rename. The fact this can be suggested this points to the symbolic nature of the names! ;-) Best, Chris |
Re: The Trunk: Graphics-mt.430.mcz
|
|
In reply to this post by Jakob Reschke
> Does it matter if the text is white on black? That was my doubt, exactly. :-)
Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <[hidden email]>
Gesendet: Montag, 20. April 2020 20:36:08 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Trunk: Graphics-mt.430.mcz Does it matter if the text is white on black?
Note that "Smalltalk classNamed: ..." is not Environments-friendly unless we changed the default binding of #Smalltalk.
Also, why not use a Symbol for the class name? The bindings all have Symbols as keys anyway, so you might trigger a conversion on each invocation. Didn't look it up though.
Tobias Pape <[hidden email]> schrieb am Sa., 18. Apr. 2020, 16:30:
Carpe Squeak!
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |