Skip navigation.
 
mlRe: Objective-C and it's future
FROM : listposter
DATE : Sat Jul 08 17:02:23 2006

On $BJ?@.(B 18/07/08, at 4:10, Thomas Davie wrote:

>
> On 8 Jul 2006, at 02:54, Sherm Pendley wrote:
>

>> On Jul 7, 2006, at 9:40 PM, Thomas Davie wrote:
>>

>>> I've yet to spend any time tracking down runtime bugs that were 
>>> not a "logical flaw" (i.e. me misinterpreting my model for how a 
>>> program should run) when writing a Haskell (strongly typed 
>>> functional language) program.

>>
>> Well, if Haskell's has everything you want, why not just use Haskell?
>>
>>     <http://hoc.sourceforge.net/>

>
> I didn't know that existed - but it does appear that it hasn't been 
> updated since panther was released :(
>
> This at least shows that there's nothing we're doing with Cocoa 
> that inherently needs a weakly typed language, so why are the 
> constraints not added?

Really? (I will be on topic as this is relevant to cocoa)

Then how does Key-Value-Bindings/Key-Value-Coding work? How would you 
switch an intermediate proxy class for the real thing in a strongly 
typed language?
Imagine your array that you wanted to ensure was "the right class" so 
you make sure that it can only contain "MyPerson" class.
When you invoke a key-value-coding method, to get some "Persons" like 
[anArrayOfPeople mutableSetValueForKey:"persons"] and you restrict your
resulting array to only allow class of "MyPerson" you would run 
afoul. Thats because mutableSetValueForKey and other KVC methods 
return proxies.
The reason proxies are used is that they allow custom logic to be 
used if one has defined methods that act for custom data. So if I 
told each item in the
array [setValue:@"blablabla" forKey:@"name"] it would invoke the 
custom logic for the value name (setName:) if it exists for each 
object. But note, you don't have to care
if the object you are sending a value to has custom logic (so you 
don't need to call setName:). Furthermore, using proxies allows the 
framework designers
to add more functionality easily -  if the future coredata allowed 
remote database access, it would most likely be transparent to the 
framework user in this case because the
proxy would handle traversing the network. It isolates you from a lot 
of "generic" work.

In the past few years cocoa has evolved tremendously from a base 
functionality point of view, all without adding to (complicating) the 
language.
This is key IMO. The language is simple, elegant, and allows for so 
much flexibility that a lot can be done just by adding to the 
runtime, not
by adding tons of complicated syntax.... and all without an ugly/slow 
VM too!

IMHO generics is overrated. Use cocoa/objective-c more, and you might 
agree.


Andre
<email_removed>

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