The Inbox: Collections-CW.640.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: Collections-CW.640.mcz

commits-2
A new version of Collections was added to project The Inbox:
http://source.squeak.org/inbox/Collections-CW.640.mcz

==================== Summary ====================

Name: Collections-CW.640
UUID: a0706e52-62c7-4ec4-b22b-6d99aa062158
Ancestors: Collections-cmm.639

constantNameFor: handles all untypeable characters

=============== Diff against Collections-cmm.639 ===============

Item was changed:
  ----- Method: Character class>>constantNames (in category 'private') -----
  constantNames
+
+ ^ self class organization listAtCategoryNamed: 'accessing untypeable characters'
+ !
- ^ #( backspace cr delete escape lf null newPage space tab ).!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-CW.640.mcz

Chris Muller-3
Given that this list will not change very often, just having it
hardcoded seems fine.

On Wed, Apr 13, 2016 at 8:13 AM,  <[hidden email]> wrote:

> A new version of Collections was added to project The Inbox:
> http://source.squeak.org/inbox/Collections-CW.640.mcz
>
> ==================== Summary ====================
>
> Name: Collections-CW.640
> UUID: a0706e52-62c7-4ec4-b22b-6d99aa062158
> Ancestors: Collections-cmm.639
>
> constantNameFor: handles all untypeable characters
>
> =============== Diff against Collections-cmm.639 ===============
>
> Item was changed:
>   ----- Method: Character class>>constantNames (in category 'private') -----
>   constantNames
> +
> +       ^ self class organization listAtCategoryNamed: 'accessing untypeable characters'
> + !
> -       ^ #( backspace cr delete escape lf null newPage space tab ).!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-CW.640.mcz

Eliot Miranda-2


> On Apr 13, 2016, at 7:50 AM, Chris Muller <[hidden email]> wrote:
>
> Given that this list will not change very often, just having it
> hardcoded seems fine.

+1.  Plus chaos will ensue if one weed to try and produce a deployment image that discarded class organization.

IMO it's find for non-trunk packages that are development oriented (such as VMMaker) to use class and system organization, and of course the programming tools interact with them.  But base library code should not assume organizations are present.  It's been a common thing to discard organizations when constructing deployment images for many years.

>> On Wed, Apr 13, 2016 at 8:13 AM,  <[hidden email]> wrote:
>> A new version of Collections was added to project The Inbox:
>> http://source.squeak.org/inbox/Collections-CW.640.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Collections-CW.640
>> UUID: a0706e52-62c7-4ec4-b22b-6d99aa062158
>> Ancestors: Collections-cmm.639
>>
>> constantNameFor: handles all untypeable characters
>>
>> =============== Diff against Collections-cmm.639 ===============
>>
>> Item was changed:
>>  ----- Method: Character class>>constantNames (in category 'private') -----
>>  constantNames
>> +
>> +       ^ self class organization listAtCategoryNamed: 'accessing untypeable characters'
>> + !
>> -       ^ #( backspace cr delete escape lf null newPage space tab ).!
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-CW.640.mcz

marcel.taeumel
We have hard-coded categories in only a very few places such as

AbstractEvent class >> #allItemKinds
AbstractSound class >> #initSounds
AbstractSound class >> #updateFMSounds

There, however, contents are variable and may change. I agree that there is no need to make such a modification in this context.

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-CW.640.mcz

Tobias Pape

On 13.04.2016, at 17:44, marcel.taeumel <[hidden email]> wrote:

> We have hard-coded categories in only a very few places such as
>
> AbstractEvent class >> #allItemKinds
> AbstractSound class >> #initSounds
> AbstractSound class >> #updateFMSounds
>
> There, however, contents are variable and may change. I agree that there is
> no need to make such a modification in this context.

Magritte used to use categories to identify its descriptions.
Now it uses pragmas/method annotations for that.

Best
        -Tobias

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-CW.640.mcz

marcel.taeumel
Part of this discussion is related to tools. Message categories are just too easy to change. How many of you do "full text search" or "string search" any time they add/remove/change a message category?

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-CW.640.mcz

Chris Muller-3
Tests are just as much a part of the tools and development process.
We have the SUnit tool to expose that.



On Wed, Apr 13, 2016 at 1:56 PM, marcel.taeumel <[hidden email]> wrote:

> Part of this discussion is related to tools. Message categories are just too
> easy to change. How many of you do "full text search" or "string search" any
> time they add/remove/change a message category?
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/The-Inbox-Collections-CW-640-mcz-tp4889722p4889777.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-CW.640.mcz

Bert Freudenberg
In reply to this post by commits-2
On 13.04.2016, at 13:13, [hidden email] wrote:

>
> A new version of Collections was added to project The Inbox:
> http://source.squeak.org/inbox/Collections-CW.640.mcz
>
> ==================== Summary ====================
>
> Name: Collections-CW.640
> UUID: a0706e52-62c7-4ec4-b22b-6d99aa062158
> Ancestors: Collections-cmm.639
>
> constantNameFor: handles all untypeable characters
>
> =============== Diff against Collections-cmm.639 ===============
>
> Item was changed:
>  ----- Method: Character class>>constantNames (in category 'private') -----
>  constantNames
> +
> + ^ self class organization listAtCategoryNamed: 'accessing untypeable characters'
> + !
> - ^ #( backspace cr delete escape lf null newPage space tab ).!
Not a good idea. The class organization is informational only and should not be used to affect behavior. E.g. it gets zapped when abandoning sources (to deploy a minimal system) and after that things would break.

We might use something like

names := Set new.
Character class selectorsAndMethodsDo: [:sel :m |
        (m numArgs = 0 and: [(m at: m initialPC+ 2) = 202])
                ifTrue: [names add: sel]].
names

... but if so then we’d better add a test that it does the right thing because it looks a bit fragile.

If we really wanted a robust enumeration of selectors then it seems best to add a pragma to each of the methods, e.g. <namedConstant>, and filter methods for that.

But IMHO the old way of explicitly listing the constant names in a literal array is the simplest option, and good enough.

- Bert -






smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-CW.640.mcz

marcel.taeumel
In reply to this post by Chris Muller-3
Hi Chris,

I am not exactly sure what you mean by that but yes: we can write a test for that. :-) Or are you referring to the test* prefix in test selectors?

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-CW.640.mcz

Chris Muller-3
You had expressed concern about code having a dependence on categories
/ protocols.  You wrote:

> Part of this discussion is related to tools. Message categories are just too
> easy to change. How many of you do "full text search" or "string search" any
> time they add/remove/change a message category?

I assumed your concern was that we don't have any tools to "alert us"
if a message category which is depended on by code, would be changed.

SUnit and its tools allows this sort of late-binding to be feasible.
We use it to assert what certain behaviors *should* be.  i.e., we
could add a test to require teh presence of certain protocols.

Or, even better, maybe some startup method on class-side could simply
ensure the necessary protocols would be present (creating them, if
necessary) to address Berts concern about stripping sources (does that
strip protocols too?).

<pine>We've heard Java advocates use the marketing phrase "type safe"
but we know "safe" is misleading.  The app could still have a
NullPointnerException, DivideByZero, FileNotFound, etc.  So they
actually just need JUnit more than they need early-binding.  Yes,
early-binding supports better code-completion tool but... the rest is
pure cost, IMHO).</pine>

Best,
  Chris

On Thu, Apr 14, 2016 at 2:49 AM, marcel.taeumel <[hidden email]> wrote:

> Hi Chris,
>
> I am not exactly sure what you mean by that but yes: we can write a test for
> that. :-) Or are you referring to the test* prefix in test selectors?
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/The-Inbox-Collections-CW-640-mcz-tp4889722p4889841.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>