The Inbox: Collections-CW.640.mcz

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

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:

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

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

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

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

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:

On 13.04.2016, at 13:13, [hidden email] wrote: 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 -

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

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: