Skip navigation.
 
mlRe: Objective-C and it's future
FROM : Thomas Davie
DATE : Sat Jul 08 03:12:36 2006

On 8 Jul 2006, at 02:00, Gregory Weston wrote:

> Thomas Davie wrote:
>

>> However, when we are dealing with much more abstract concepts such as
>> objects, we generally know what our data structures are.  We know how
>> they are going to be used, and we know what they should and should
>> not do.

>
> But notice what you said there. Or what you didn't. You indicated 
> that we know and care about _behavior_. Not structure, nor 
> appearance, nor type. We just want to know that when we send "this 
> message" we'll get a response that, itself, only needs to conform 
> to certain behavior. We don't really want collections to be of 
> certain specific types because there's no reason to restrict a 
> collection to holding only one type of data. That may not be so 
> obvious for a traditional integer-index array, but consider an 
> associative array. I rarely want a dictionary in which _every_ key 
> is a string and _every_ value is a numeric value.


On the contrary, you just need a good type system.  For example, the 
constraint that I want all elements in the array to be comparable 
would be something akin to asking in (for example) Haskell that all 
elements in a list to be sorted must be comparable...  This is written

sort :: Ord a => [a] -> [a]

That is - if the type 'a' is orderable (i.e. it responds to functions 
about ordering), then the sort function maps lists containing objects 
of type a to lists containing objects of type a.  If the elements of 
the list are not orderable, then sorting cannot be applied.

This constrains us to all elements being the same the same type (as 
long as it's orderable), which is not quite what we want, we want, 
the objects to be any one of many different types as long as they are 
orderable.

So, supposing we want an array containing only NSStrings, we might 
invent this syntax:

NSArray[NSString]* foo;

if we want an array of objects that accept comparison methods we 
might specify

NSArray([id]<NSComprable>)* foo;

If we want an array where all objects are the same type and all 
objects accept comparison methods we might specify

NSArray[id <NSComparable>]* foo;

If we want a truely dynamic array (as we have at the moment we might 
write

NSArray[id]* foo;

or even have the normal syntax default to this definition.

Now obviously here I'm inventing syntax and some framework, but this 
provides enough power to describe all the situations you want to.  So 
what's against having this descriptive power in the language when 
it's very useful for checking the correctness of the program.

Bob

Related mailsAuthorDate
mlObjective-C and it's future Thomas Davie Jul 8, 01:33
mlRe: Objective-C and it's future Finlay Dobbie Jul 8, 01:46
mlRe: Objective-C and it's future Shawn Erickson Jul 8, 01:48
mlRe: Objective-C and it's future Charlton Wilbur Jul 8, 01:55
mlRe: Objective-C and it's future Thomas Davie Jul 8, 02:10
mlRe: Objective-C and it's future Robert Walker Jul 8, 02:12
mlRe: Re: Objective-C and it's future Shawn Erickson Jul 8, 02:22
mlRe: Objective-C and it's future Rob Ross Jul 8, 02:29
mlRe: Re: Objective-C and it's future Shawn Erickson Jul 8, 02:41
mlRe: Objective-C and it's future Thomas Davie Jul 8, 02:42
mlRe: Objective-C and it's future Erik Buck Jul 8, 02:50
mlRe: Objective-C and it's future Kenny Leung Jul 8, 02:57
mlRe: Objective-C and it's future Gregory Weston Jul 8, 03:00
mlRe: Objective-C and it's future Damien Sorresso Jul 8, 03:00
mlRe: Objective-C and it's future Damien Sorresso Jul 8, 03:00
mlRe: Re: Objective-C and it's future Shawn Erickson Jul 8, 03:07
mlRe: Objective-C and it's future Thomas Davie Jul 8, 03:12
mlRe: Objective-C and it's future Damien Sorresso Jul 8, 03:14
mlRe: Objective-C and it's future Rob Ross Jul 8, 03:15
mlRe: Objective-C and it's future Rob Ross Jul 8, 03:18
mlRe: Re: Objective-C and it's future Shawn Erickson Jul 8, 03:23
mlRe: Re: Objective-C and it's future Shawn Erickson Jul 8, 03:25
mlRe: Objective-C and it's future Thomas Davie Jul 8, 03:28
mlRe: Objective-C and it's future Thomas Davie Jul 8, 03:40
mlRe: Objective-C and it's future Sherm Pendley Jul 8, 03:54
mlRe: Objective-C and it's future Kenny Leung Jul 8, 03:56
mlRe: Objective-C and it's future Shawn Erickson Jul 8, 04:22
ml[Moderator] Re: Objective-C and it's future cocoa-dev-admins Jul 8, 04:56
mlRe: Objective-C and it's future Thomas Davie Jul 8, 13:10
mlRe: Objective-C and it's future listposter Jul 8, 17:02
mlRe: Objective-C and it's future cocoa-dev-admins Jul 8, 17:05
mlRe: Objective-C and it's future John C. Randolph Jul 8, 18:50
mlRe: Objective-C and it's future Ryan Stevens Jul 8, 19:13
mlRe: Objective-C and it's future Scott Thompson Jul 10, 16:21
mlRe: Objective-C and it's future Andrew Satori Jul 10, 16:43
ml[Modertator] Re: Objective-C and it's future cocoa-dev-admins Jul 10, 17:13