[7.9.1] feedback on bogus #size implementations

The following methods are just plain wrong. They should answer 0, not throw errors. There are many, many classes which are not element indexable, and they all answer 0.

 

 

Integer>>size
LimitedPrecisionReal>>size
PacketValue>>size
UninterpretedBytes>>size


size
    "Override implementation in Object since Integer
    instances are not element indexable using this protocol."

    ^self shouldNotImplement

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The following methods are just plain wrong. They should answer 0, not throw errors. There are many, many classes which are not element indexable, and they all answer 0.

 

 

Integer>>size
LimitedPrecisionReal>>size
PacketValue>>size
UninterpretedBytes>>size


size
    "Override implementation in Object since Integer
    instances are not element indexable using this protocol."

    ^self shouldNotImplement

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

You started off well, but fell apart when you decided that the definition of size was something other than it has been defined to be for 30+ years.

 

>> And you also say they should all answer zero.
>> Here, I disagree.
>>
>> I say they should all answer 1,

---

From: [hidden email] [[hidden email]] On Behalf Of jas
Sent: June 16, 2014 22:24
To: [hidden email]
Subject: Re: [vwnc] [7.9.1] feedback on bogus #size implementations

The actual problem here is the bogus definition of #size, i.e. the message itself.

Does it mean:
    o    How much space do you take?     Problem: what is -space- and how big is it?
    o    How many indexed instance variables do you have?
    o    How many elements do you currently have?
    o    How many elements can you hold?
    o    Can you hold elements and if so how many, or if not SIGNAL an error.

Depends who (what object) you ask.

It also depends who (what person) you ask.

You say these (the examples you cite, below) are all wrong.
I agree.

And we also agree that #size should not be signalling an Error.
Not ever.

And you also say they should all answer zero.
Here, I disagree.

I say they should all answer 1,
    - because
          an object that is not element indexable
          represents just itself, which is something,
          and something is some thing, not no thing,
      and has an element count of 1,     ( me + myself + I ~= 3 and: [ me + myself + I  ~= 0] )
      and a {virtual} element index of 1,
      {and also marshaler's should be looking elsewhere anyway}.

E.g.

    If you have a box of 12 count bottles of ketchup(sic)
    and ask "How many bottles of ketchup?" the answer is 12.

    If you take away the box and replace it with a bottle of ketchup,
    and ask again "How many bottles of ketchup?" what do you want the answer to be?

    If you take away the bottle and replace it with nil *or* with an empty box,
    and ask again, what do you want the answer to be?

    Now, is this what -size- means?

    It *could* mean "How tall are you?"
    Or "How much do you weigh?"
    Or "What is your volume?"
    Or "How many trucks does it take to carry you home?"

    But all of those require additional knowledge - a base unit or standard unit.

    Whereas if #size means "How many whatevers?"
    anything can answer that,
    and we don't even need to first agree on the meaning of 'whatevers',
    because that is an encapsulated detail.

But I'm a hob-goblin for these sorts of things.
Your mileage may vary.

Regards,

-cstb

On 6/15/2014 12:33 PM, Richard Sargent wrote:

The following methods are just plain wrong. They should answer 0, not throw errors. There are many, many classes which are not element indexable, and they all answer 0.

 

 

Integer>>size
LimitedPrecisionReal>>size
PacketValue>>size
UninterpretedBytes>>size


size
    "Override implementation in Object since Integer
    instances are not element indexable using this protocol."

    ^self shouldNotImplement

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

jas,

 

Having Integer>>size answer 1 would be for a different purpose than is conventional.

 

It reminds me of extensions for polymorphism at the object level that I had used many years ago, and had long since forgotten. I'd extended base classes so that they could respond to #itemsDo: and #itemsSize. #itemsDo: would do a shallow enumeration of the receiver or items in a collection. Object>>itemsSize would answer 1 by default, as the receiver would be enumerated by #itemsDo:; for example:

 

#(one two three (four five)) itemsSize

4

 

"#one itemsSize" is an example of where there can be confusion; should it respond 1 or 3? You'd generally want the CharacterArray to treat itself as an item rather than count each character as an item. For greatest utility the #itemsDo: and #itemsSize would use the string itself as one item, but that would be considered a flaw to someone who desires to enumerate the characters. It is important to settle on the most useful convention and be consistent with it. It is also important that people can implement their own extensions to meet their unique needs.

 

Another example of where there could be confusion is whether #itemsDo: on a Dictionary would use associations as items or values of the associations as items. Good arguments could be made for either way. It is up to the architect to decide which way to go, and up to users to decide how useful his choices were in a market of alternatives.

 

By common convention, Integer>>size should answer 0 rather than error. I don't need to care about statisfying every possible need. It is more important not to break the convention that had been established.

 

Paul Baumann

 

 

 

From: [hidden email] [[hidden email]] On Behalf Of Richard Sargent
Sent: Tuesday, June 17, 2014 02:37
To: 'jas'; [hidden email]
Subject: Re: [vwnc] [7.9.1] feedback on bogus #size implementations

 

You started off well, but fell apart when you decided that the definition of size was something other than it has been defined to be for 30+ years.

 

>> And you also say they should all answer zero.
>> Here, I disagree.
>>
>> I say they should all answer 1,

 

---

From: [hidden email] [[hidden email]] On Behalf Of jas
Sent: June 16, 2014 22:24
To: [hidden email]
Subject: Re: [vwnc] [7.9.1] feedback on bogus #size implementations

The actual problem here is the bogus definition of #size, i.e. the message itself.

Does it mean:
    o    How much space do you take?     Problem: what is -space- and how big is it?
    o    How many indexed instance variables do you have?
    o    How many elements do you currently have?
    o    How many elements can you hold?
    o    Can you hold elements and if so how many, or if not SIGNAL an error.

Depends who (what object) you ask.

It also depends who (what person) you ask.

You say these (the examples you cite, below) are all wrong.
I agree.

And we also agree that #size should not be signalling an Error.
Not ever.

And you also say they should all answer zero.
Here, I disagree.

I say they should all answer 1,
    - because
          an object that is not element indexable
          represents just itself, which is something,
          and something is some thing, not no thing,
      and has an element count of 1,     ( me + myself + I ~= 3 and: [ me + myself + I  ~= 0] )
      and a {virtual} element index of 1,
      {and also marshaler's should be looking elsewhere anyway}.

E.g.

    If you have a box of 12 count bottles of ketchup(sic)
    and ask "How many bottles of ketchup?" the answer is 12.

    If you take away the box and replace it with a bottle of ketchup,
    and ask again "How many bottles of ketchup?" what do you want the answer to be?

    If you take away the bottle and replace it with nil *or* with an empty box,
    and ask again, what do you want the answer to be?

    Now, is this what -size- means?

    It *could* mean "How tall are you?"
    Or "How much do you weigh?"
    Or "What is your volume?"
    Or "How many trucks does it take to carry you home?"

    But all of those require additional knowledge - a base unit or standard unit.

    Whereas if #size means "How many whatevers?"
    anything can answer that,
    and we don't even need to first agree on the meaning of 'whatevers',
    because that is an encapsulated detail.

But I'm a hob-goblin for these sorts of things.
Your mileage may vary.

Regards,

-cstb

On 6/15/2014 12:33 PM, Richard Sargent wrote:

The following methods are just plain wrong. They should answer 0, not throw errors. There are many, many classes which are not element indexable, and they all answer 0.

 

 

Integer>>size
LimitedPrecisionReal>>size
PacketValue>>size
UninterpretedBytes>>size


size
    "Override implementation in Object since Integer
    instances are not element indexable using this protocol."

    ^self shouldNotImplement

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

 

---

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

 "Answer the number of indexed variables in the receiver (0 for non-indexable objects,
 as the named instance variables are not included). The primitive should not fail."

You started off well, but fell apart when you decided that the definition of size was something other than it has been defined to be for 30+ years.

 

>> And you also say they should all answer zero.
>> Here, I disagree.
>>
>> I say they should all answer 1,

---

From: [hidden email] [[hidden email]] On Behalf Of jas
Sent: June 16, 2014 22:24
To: [hidden email]
Subject: Re: [vwnc] [7.9.1] feedback on bogus #size implementations

The actual problem here is the bogus definition of #size, i.e. the message itself.

Does it mean:
    o    How much space do you take?     Problem: what is -space- and how big is it?
    o    How many indexed instance variables do you have?
    o    How many elements do you currently have?
    o    How many elements can you hold?
    o    Can you hold elements and if so how many, or if not SIGNAL an error.

Depends who (what object) you ask.

It also depends who (what person) you ask.

You say these (the examples you cite, below) are all wrong.
I agree.

And we also agree that #size should not be signalling an Error.
Not ever.

And you also say they should all answer zero.
Here, I disagree.

I say they should all answer 1,
    - because
          an object that is not element indexable
          represents just itself, which is something,
          and something is some thing, not no thing,
      and has an element count of 1,     ( me + myself + I ~= 3 and: [ me + myself + I  ~= 0] )
      and a {virtual} element index of 1,
      {and also marshaler's should be looking elsewhere anyway}.

E.g.

    If you have a box of 12 count bottles of ketchup(sic)
    and ask "How many bottles of ketchup?" the answer is 12.

    If you take away the box and replace it with a bottle of ketchup,
    and ask again "How many bottles of ketchup?" what do you want the answer to be?

    If you take away the bottle and replace it with nil *or* with an empty box,
    and ask again, what do you want the answer to be?

    Now, is this what -size- means?

    It *could* mean "How tall are you?"
    Or "How much do you weigh?"
    Or "What is your volume?"
    Or "How many trucks does it take to carry you home?"

    But all of those require additional knowledge - a base unit or standard unit.

    Whereas if #size means "How many whatevers?"
    anything can answer that,
    and we don't even need to first agree on the meaning of 'whatevers',
    because that is an encapsulated detail.

But I'm a hob-goblin for these sorts of things.
Your mileage may vary.

Regards,

-cstb

On 6/15/2014 12:33 PM, Richard Sargent wrote:

The following methods are just plain wrong. They should answer 0, not throw errors. There are many, many classes which are not element indexable, and they all answer 0.

 

 

Integer>>size
LimitedPrecisionReal>>size
PacketValue>>size
UninterpretedBytes>>size


size
    "Override implementation in Object since Integer
    instances are not element indexable using this protocol."

    ^self shouldNotImplement

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

+1

 

Terry

 

===========================================================

Terry Raymond

Crafted Smalltalk

80 Lazywood Ln.

Tiverton, RI  02878

(401) 624-4517      [hidden email]

===========================================================

 

From: [hidden email] [[hidden email]] On Behalf Of Richard Sargent
Sent: Saturday, June 21, 2014 4:55 PM
To: 'jas'; [hidden email]
Subject: Re: [vwnc] [7.9.1] feedback on bogus #size implementations

 

>> Because the definition of #size is,  what?
I'll take it from Dolphin, which has one of most articulate set of method comments I've come across.

 "Answer the number of indexed variables in the receiver (0 for non-indexable objects,
 as the named instance variables are not included). The primitive should not fail."

The object itself is not one of its indexed instance variables. Don't conflate the container with the contained.

 

I think you are looking to model something different from what Smalltalk has defined. For what I *think* you are after, the pattern  of #whatevers, #allWhatevers, and #WithAllWhatevers is what you are looking for. If you want to enumerate an object, and its named instance variables, and its indexed instance variables, feel free to do so. Define your API, but don't try to hijack Smalltalk's well-defined API for purposes other than it is intended for.

 

 

>> It is the not-really-determined part that I'm concerned with.
>> For example - OrderedCollection responds to size with ?
I know of no "not-really-determined" part of #size. You cannot suggest that OrderedCollection new size should answer 1, can you?

 

---

From: jas [[hidden email]]
Sent: June 20, 2014 15:35
To: Richard Sargent; [hidden email]
Subject: Re: [vwnc] [7.9.1] feedback on bogus #size implementations

Thanks Richard.

Yeah, I'd have spoken up sooner, but
its only bothered me for the last 20 or so. ;-)

It is the not-really-determined part that I'm concerned with.
For example - OrderedCollection responds to size with ?
Because the definition of #size is,  what?

If your examples all answered 0
it would be an improvement, so I'd support that.

Then I'd deprecate all the 0 responses for a release
or two and then change them all to 1.  But that's just me.
It would take a lot more interests than just mine to
make an action item out of that thought.

So - I think 1 is logically a better answer,
and also one I can define with some clarity.
So I would.

Assuming a reasonable timeframe for convergence,
would you still prefer 0?

Regards,

-cstb

 



 On 6/16/2014 11:37 PM, Richard Sargent wrote:

You started off well, but fell apart when you decided that the definition of size was something other than it has been defined to be for 30+ years.

 

>> And you also say they should all answer zero.
>> Here, I disagree.
>>
>> I say they should all answer 1,

 

---

From: [hidden email] [[hidden email]] On Behalf Of jas
Sent: June 16, 2014 22:24
To: [hidden email]
Subject: Re: [vwnc] [7.9.1] feedback on bogus #size implementations

The actual problem here is the bogus definition of #size, i.e. the message itself.

Does it mean:
    o    How much space do you take?     Problem: what is -space- and how big is it?
    o    How many indexed instance variables do you have?
    o    How many elements do you currently have?
    o    How many elements can you hold?
    o    Can you hold elements and if so how many, or if not SIGNAL an error.

Depends who (what object) you ask.

It also depends who (what person) you ask.

You say these (the examples you cite, below) are all wrong.
I agree.

And we also agree that #size should not be signalling an Error.
Not ever.

And you also say they should all answer zero.
Here, I disagree.

I say they should all answer 1,
    - because
          an object that is not element indexable
          represents just itself, which is something,
          and something is some thing, not no thing,
      and has an element count of 1,     ( me + myself + I ~= 3 and: [ me + myself + I  ~= 0] )
      and a {virtual} element index of 1,
      {and also marshaler's should be looking elsewhere anyway}.

E.g.

    If you have a box of 12 count bottles of ketchup(sic)
    and ask "How many bottles of ketchup?" the answer is 12.

    If you take away the box and replace it with a bottle of ketchup,
    and ask again "How many bottles of ketchup?" what do you want the answer to be?

    If you take away the bottle and replace it with nil *or* with an empty box,
    and ask again, what do you want the answer to be?

    Now, is this what -size- means?

    It *could* mean "How tall are you?"
    Or "How much do you weigh?"
    Or "What is your volume?"
    Or "How many trucks does it take to carry you home?"

    But all of those require additional knowledge - a base unit or standard unit.

    Whereas if #size means "How many whatevers?"
    anything can answer that,
    and we don't even need to first agree on the meaning of 'whatevers',
    because that is an encapsulated detail.

But I'm a hob-goblin for these sorts of things.
Your mileage may vary.

Regards,

-cstb

On 6/15/2014 12:33 PM, Richard Sargent wrote:

The following methods are just plain wrong. They should answer 0, not throw errors. There are many, many classes which are not element indexable, and they all answer 0.

 

 

Integer>>size
LimitedPrecisionReal>>size
PacketValue>>size
UninterpretedBytes>>size


size
    "Override implementation in Object since Integer
    instances are not element indexable using this protocol."

    ^self shouldNotImplement

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc