[7.9.1] feedback on bogus #size implementations

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

[7.9.1] feedback on bogus #size implementations

Richard Sargent
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

Paul Baumann

I agree. It is a common technique to use "x size = 0" instead of "x isEmpty" because #size is compatible with non-collections (nil is a common substitute). Problems have occurred when integers were used with the #size technique and when an integer was also a valid value. It isn't a common problem, but our VW code now has several #isInteger tests to avoid the error. An example of when an #isInteger test would be used to avoid that stupid error is a marshaling framework that visits a graph of various kinds of objects. Every object should be able to respond to #size without throwing an error. #size should respond the logical size (which by default is the #basicSize number of indexable fields). Marshaling frameworks usually have to resort to defining and maintaining a mostly duplicate notion of size to avoid problems like this.

 

Paul Baumann

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Richard Sargent
Sent: Sunday, June 15, 2014 15:33
To: 'VW NC'
Subject: [vwnc] [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



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.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

Andres Valloud-4
In reply to this post by Richard Sargent
IIRC in some cases those methods shouldn't matter because e.g. one isn't
supposed to create instances of said classes in the first place.  In
some other cases, like UninterpretedBytes, I'd look at the larger
context in which size is implemented... although I do not recall exactly
right now, I feel that there is a reason why UninterpretedBytes behaves
that way, and it has to do with its purpose in life.

On 6/15/14 12:33 , 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
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

Paul Baumann
I suspect that it is because LargeInteger has an indexable structure that someone thought it beneficial to answer with an error:

        200reallyLargeInteger basicSize
         16

Same goes for LimitedPrecisionReal:

        200reallyLargeInteger asDouble basicSize
         8

All numbers should answer 0 when asked #size, for the same reason that "(Dictionary new: 2000) size" would answer zero instead of the #basicSize value 2003. An exception for answering 0 for #size would be an advanced magnitude framework that implements number sets. When numbers throw an error for #size then frameworks like that have to use VW-specific base class extensions to avoid those problems.

Paul Baumann


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Andres Valloud
Sent: Monday, June 16, 2014 10:41
To: Visualworks Mailing List
Subject: Re: [vwnc] [7.9.1] feedback on bogus #size implementations

IIRC in some cases those methods shouldn't matter because e.g. one isn't supposed to create instances of said classes in the first place.  In some other cases, like UninterpretedBytes, I'd look at the larger context in which size is implemented... although I do not recall exactly right now, I feel that there is a reason why UninterpretedBytes behaves that way, and it has to do with its purpose in life.

On 6/15/14 12:33 , 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.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
jas
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

jas
In reply to this post by Richard Sargent
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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

Andres Valloud-4
> And we also agree that #size should not be signalling an Error.
> Not ever.

You know, the hard part is dealing with the details.

So what happens if you have a database proxy to a string, you unplug the
ethernet cable, and send #size to the proxy?  Wouldn't you expect some
exception to come up?

What if you have some object that symbolically represents a huge number
interval such as (50 to: grahamsNumber), you send it #size, but there's
no memory to compute the result?

These types of considerations sooner or later will lead to some form of
design compromise.  Perhaps a less convoluted compromise could be found
given time to think things thoroughly.  In the mean time, though, keep
in mind compromise tends to manifest as seemingly contradictory code.

Andres.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

Richard Sargent (again)
In reply to this post by jas
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] [mailto:[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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

Paul Baumann

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] [mailto:[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.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
jas
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

jas
In reply to this post by Andres Valloud-4
On 6/16/2014 10:50 PM, Andres Valloud wrote:
>> And we also agree that #size should not be signalling an Error.
>> Not ever.
>
> You know, the hard part is dealing with the details.

Indeed - like whether to qualify that last bit, or not ;-)

Anything with a connection that isn't -up- must either wait, cheat, or
signal.
And anything that -cannot- compute an answer would need to cheat or signal.
I'd lean toward signalling for such things.

So - agreed.

-cstb

>
> So what happens if you have a database proxy to a string, you unplug
> the ethernet cable, and send #size to the proxy?  Wouldn't you expect
> some exception to come up?
>
> What if you have some object that symbolically represents a huge
> number interval such as (50 to: grahamsNumber), you send it #size, but
> there's no memory to compute the result?
>
> These types of considerations sooner or later will lead to some form
> of design compromise.  Perhaps a less convoluted compromise could be
> found given time to think things thoroughly.  In the mean time,
> though, keep in mind compromise tends to manifest as seemingly
> contradictory code.
>
> Andres.
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
jas
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

jas
In reply to this post by Richard Sargent (again)
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



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
jas
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

jas
In reply to this post by Paul Baumann
Hi Paul,

Yup - you nailed it - that is the eventual use-case.
I see you've spent some time on that path yourself.
CharacterArray (or String) is indeed problematic,
and is the only issue I've encountered in practice,
although in theory there could be others.

1. What caused you to drop your extensions?
2. Why the qualified selector names (e.g. #itemsDo:, rather than #do:) ?

As for 'common convention', sure -
    and as long as the convention stays put,
    I'd keep putting out releases that answer 0 for Integer size.

Meanwhile, I'd call it 'mistaken approach, as per convention',
and agitate (just a little) for the better answer, whatever that
turns out to be, and whatever is the source thereof.

I happen to think there is fruit to be had,
on the alternate path,
or I wouldn't go there at all, of course.

Regards,

-cstb


 
On 6/17/2014 8:34 AM, Paul Baumann wrote:

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.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

Richard Sargent (again)
In reply to this post by jas
>> 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 [mailto:[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



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

Terry Raymond

+1

 

Terry

 

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

Terry Raymond

Crafted Smalltalk

80 Lazywood Ln.

Tiverton, RI  02878

(401) 624-4517      [hidden email]

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

 

From: [hidden email] [mailto:[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

 

 


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
jas
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

jas
Hi Terry,

I'm not understanding your comment here.
What position are you indicating your support for?

Regards,

-cstb

On 6/21/2014 3:53 PM, Terry Raymond wrote:

+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

 

 



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

Terry Raymond

The Smalltalk API is well defined and has been for over 30 years, changing something

this fundamental now would be a big mistake. If you want something

with a different meaning then you add a separate facility.

 

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.

 

 

Terry

 

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

Terry Raymond

Crafted Smalltalk

80 Lazywood Ln.

Tiverton, RI  02878

(401) 624-4517      [hidden email]

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

 

From: jas [mailto:[hidden email]]
Sent: Saturday, June 21, 2014 10:20 PM
To: Terry Raymond; 'Richard Sargent'; [hidden email]
Subject: Re: [vwnc] [7.9.1] feedback on bogus #size implementations

 

Hi Terry,

I'm not understanding your comment here.
What position are you indicating your support for?

Regards,

-cstb

On 6/21/2014 3:53 PM, Terry Raymond wrote:

+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

 

 

 


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [7.9.1] feedback on bogus #size implementations

Andres Valloud-4
In reply to this post by jas
Nothing prevents anyone from creating a loadable library that implements
a better approach.  If such library existed, one could take advantage of
such code without breaking 30+ years' worth of code and convention in
the process.

On 6/20/14 16:03 , jas wrote:

> Hi Paul,
>
> Yup - you nailed it - that is the eventual use-case.
> I see you've spent some time on that path yourself.
> CharacterArray (or String) is indeed problematic,
> and is the only issue I've encountered in practice,
> although in theory there could be others.
>
> 1. What caused you to drop your extensions?
> 2. Why the qualified selector names (e.g. #itemsDo:, rather than #do:) ?
>
> As for 'common convention', sure -
>      and as long as the convention stays put,
>      I'd keep putting out releases that answer 0 for Integer size.
>
> Meanwhile, I'd call it 'mistaken approach, as per convention',
> and agitate (just a little) for the better answer, whatever that
> turns out to be, and whatever is the source thereof.
>
> I happen to think there is fruit to be had,
> on the alternate path,
> or I wouldn't go there at all, of course.
>
> Regards,
>
> -cstb
>
>
>
> On 6/17/2014 8:34 AM, Paul Baumann wrote:
>>
>> 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] [mailto:[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] <mailto:[hidden email]>
>> [mailto:[hidden email]] *On Behalf Of *jas
>> *Sent:* June 16, 2014 22:24
>> *To:* [hidden email] <mailto:[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]  <mailto:[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.
>
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc