Re: Introductions to OOP?

[Ian Joyner]

To understand the why of OO there is Bertrand Meyer's book Object-Oriented 
Software Construction:

http://docs.eiffel.com/book/method/object-oriented-software-construction-2nd-edition

It is big, but maybe the most complete and easy-to-read book on the subject. 
But you have to hang up any addiction to c-like syntax. But it will help 
understand many OO languages from the concepts down.

Another more recent book from Meyer is Touch of Class:

http://docs.eiffel.com/book/method/touch-class-learning-program-well-objects-and-contracts

but I don't have this yet.

For managers there is his Object Success book:

http://www.amazon.com/Object-Success-Object-Oriented-Technology-Corporation/dp/0131928333

which I used recently to try to convince an old-style manager that waterfall is 
mainly wrong and goes into many issues that need to be addressed in today's 
software development environments.

Ian

On 3 Sep 2011, at 09:04, koko wrote:

> Just stay away from th e1986 Byte Magazine article describing OOP ... pretty 
> funny actually.
> 
> -koko
> 
> On Sep 2, 2011, at 11:04 AM, Jens Alfke wrote:
> 
>> 
>> On Sep 1, 2011, at 9:26 PM, Julie Porter wrote:
>> 
>>> Again I am impressed with the help I received here.   Hopefully others will 
>>> be able to read these threads and learn from the experience of others.
>> 
>> Julie: You’re welcome!
>> 
>> Gang: One result of this is that I’m realizing how difficult it is to 
>> explain the basic concepts of object-oriented programming to someone who’s 
>> confused by them. I’ve been using them so long, that it’s like a fish trying 
>> to explain how to swim. I’d like to be able to point people to a good 
>> introduction, either online or in a book, but unfortunately I don’t know of 
>> any. Can anyone recommend something? (It doesn’t have to be Objective-C 
>> specific, although ideally it would describe dynamic languages, not static 
>> ones like C++ or Java.)
>> 
>> Another common stumbling block seems to be nib loading, and the concept of 
>> wiring up your non-view objects so they can find each other at runtime. I 
>> think I’m better at explaining this because I still remember learning it 
>> myself, but it would still be good to bookmark some clear descriptions.
>> 
>> —Jens___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/koko%40highrolls.net
>> 
>> This email sent to k...@highrolls.net
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ObjC's flat and all-exported namespace, help!

[Ian Joyner]

On 9 Nov 2011, at 05:21, Greg Parker wrote:

> On Nov 8, 2011, at 9:57 AM, Andy O'Meara wrote:
>> Yes, I know that one workaround is to mangle all objC class names based on 
>> something unique in the project (we are forced to do this with our 
>> screensaver products).  I'd be more accepting of this if Xcode facilitated 
>> this (with perhaps a macro of or the introduction of @privateinterface or 
>> something), but I don't fancy the idea of having to stick nasty and limiting 
>> #includes, #defines, or #ifdefs all over our code to make sure stuff 
>> compiles and links correctly just to workaround the fact that objC seems 
>> like it should really allow classes to not be exported by default into a 
>> single/shared namespace.
> 
> This is the only solution.
> 
> 
>> I suppose if there's no solution to this, then someone is going to describe 
>> how it can't be done because it would somehow break the loading of bundles.  
>> Well if that's the case, then I'm thinking that a radar is still worth 
>> filing because I'd be pretty surprised if the senior engineering level is 
>> going to agree that this whole flat objC namespace business is consistent 
>> with the precept that software should 'just work', rather than 'usually 
>> work' and emit user-attention-getting log messages as long as two internally 
>> private class names don't happen to have the same name.
> 
> 
>  ER: Objective-C namespaces
> 
> If you're familiar with Radar numbers, you'll recognize that the bug is very 
> old. The name is a bit misleading - C++ namespaces or Java packages are 
> little better than adding name prefixes by hand. (For example, they don't 
> solve the problem of two developers importing the same static archive.) A 
> real solution for class name collisions needs to be (1) automatic or nearly 
> so, (2) predictable so nib references work, and (3) not incompatible with 
> existing classes. It's a hard problem.

I agree, in NS::class, just substitute the ugly :: with _ and you see it's just 
a trick: NS_class. There should be a decent solution that doesn't need to put 
extra bookkeeping constructs in the language, and so that the clash is avoided 
in one place. Another point is that code in a class should not be bound to the 
environment and the C++ and Java way of doing it says 'environment' all over 
the place.

A different approach is in Eiffel that identifies the problem as being when you 
try to use two libraries together and handles clashes in one place by renaming 
(in a configuration file separate from code). Thus it becomes a linker concern. 
Language design should keep compilation concerns separate from linking concerns 
(and indeed not just static linking, but dynamic run-time linking). On the 
other hand most Unix style C linkers really don't do enough to make sure things 
can be sensibly linked together, so the basic languages and compilers get bent 
instead and then programmers are forced to think of all these things at a lower 
level than they should need to.

Similarly, imports and #includes are really bad, because they couple modules to 
their environment, rather than this kind of linkage being done externally in 
one place and handled by the linker. This means that if any import changes, you 
have to go through all the files and change all the imports and it looks like 
you are programming, but really you are not. So we invent a refactoring to take 
care of something that shouldn't exist.

Anyway, that's my argument for not doing namespaces in Objective-C the Java or 
C++ way. There's not so much clutter in Java, but there is so much clutter in 
C++ it looks like Windows! I'm sure Apple will come up with a better solution 
and things they have done over the last few years with Objective-C (and tagged 
pointers in Lion as we have just discussed in the Obj-C group) have been very 
nice and simplifying (even for a language based on C). We should not force them 
into doing anything the same bad old way that everything else does.

Ian
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ObjC's flat and all-exported namespace, help!

[Ian Joyner]

On 9 Nov 2011, at 22:44, Andreas Grosam wrote:

> 
> On Nov 9, 2011, at 12:11 PM, Karl Goiser wrote:
> 
>> Your first option looks better to me!
>> :-)
>> 
>> All I’m saying is that Objective C is a very mature language now
> Depending on your perspective, you can say this for many languages. But only 
> the dead ones do not evolve (Objective-C, does it, though)
> 
>> and if it has been able to get by
> You should ask the *developers*, not the *language*, if they experience 
> issues and if they feel comfortable to workaround these issues.
> 
>> without adding this extra layer of complexity, why introduce it for an edge 
>> case to address a situation where people are expecting it to act like C++?
> I wouldn't say it is an edge case. If you develop small applications in a 
> one-man company, and no plugins, you may feel this as a minor issue.
> Others won't agree, and actually have a big problem.
> 
> Namespaces for Objective-C will likely not require the same feature set than 
> what is available in C++ (e.g., no argument dependent lookup). There is also 
> no need to do this. The only thing that should be considered when introducing 
> namespaces in my opinion is, that it should be seamlessly integrated into 
> Objective-C++. The negative asset against C++ made from a few posters here, 
> is futile - Objective-C will have and be Objective-C++ as well. This requires 
> to consider C++ syntax - and IMHO, regarding namespaces, it isn't ugly at all.

Well, a lot of folk consider that Windows isn't ugly, after all they find it 
useful to do some work. But it is ugly!

Let's forget the subjective term ugly. Why is it not good? The same reasoning 
is like the goto argument. Dijkstra pointed out gotos considered harmful, and 
Knuth said you could do structured programming with gotos. Both were correct.

The problem with C is that it exposes too much low-level stuff that makes code 
inflexible and doesn't add anything to the power of the language. For example C 
pointers are the data structure equivalent of gotos. That is coming from the 
bottom up, so that stuff that is at a lower level than should be in an 
algorithmic language is exposed.

The problem with C++'s namespace mechanism, is it's exposing the opposite, the 
higher-level organizational aspects, and putting these in the programming 
language. Thus the higher level that should also not be in a programming 
language is exposed. This complicates the programming activity and hides the 
true purpose of a computation. This is a concern.

A parallel with aspect-oriented programming is that AOP attempts to remove 
cross-cutting concerns from regular code, so that the real purpose of a 
computation is clear.

Modularization aspects (at least the mixing of modules) really should not be a 
part of the language. We program a module, but it should be as independent from 
its environment as possible. That is essential to reuse. Imports and #includes 
expose the environment internally in a module.

We are progressing towards this and C++'s implementation of namespaces really 
goes in the opposite direction.

It's the old I have a hammer so everything looks like a nail, but in C++'s case 
it's I have a programming language, so everything gets put in that. We really 
need to get away from that kind of thinking about programming languages and get 
back towards the Smalltalk ideal. Objective-C does that, which makes it the 
nicest flavour of C. The programming community needs to learn what the phrase 
'separation of concerns' really means.
> 
>> 
>> Apple, after all is all about being simple and clean, and its language of 
>> choice should reflect that because, after all, it’s the developers who 
>> create the simple and clean.  In my opinion, Objective C is an embodiment of 
>> the Apple attitude.
> From the developers view, using namespaces shouldn't appear to be complex and 
> its usage should be certainly optional. IMHO, Objective-C could stay without 
> having namespaces. C is required to use the same approach to avoid name 
> conflicts: prefixes. However, introducing namespaces to Objective-C++ could 
> be worthwhile to investigate if this is feasable. IFF, then integrating 
> namespaces with C++ possibly could be done seamlessly.
> 
> Andreas
> 
>> 
>> My favourite saying of all time is, “to a person with a hammer, everything 
>> looks like a nail.”  Objective C is a screw, and you use a screwdriver on 
>> it, nor a hammer.
>> 
>> 
>> As far as versioning issues from the same class in two bundles is concerned, 
>> if the class works to spec, there’s no problem.  If it doesn’t, that’s a 
>> bug, and wouldn’t the bundles have to be updated anyway?
>> 
>> Karl
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lis

Re: ObjC's flat and all-exported namespace, help!

[Ian Joyner]

On 10 Nov 2011, at 21:13, Karl Goiser wrote:

> 
> On 10/11/2011, at 12:04 PM, Ian Joyner wrote:
> 
>> It's the old I have a hammer so everything looks like a nail, but in C++'s 
>> case it's I have a programming language, so everything gets put in that. We 
>> really need to get away from that kind of thinking about programming 
>> languages and get back towards the Smalltalk ideal. Objective-C does that, 
>> which makes it the nicest flavour of C. The programming community needs to 
>> learn what the phrase 'separation of concerns' really means.
> 
> Hear hear!
> 
> 
> Sure, Objective C exposes a lot of internals for those who are looking for it.

Yes, that's troubling in a way, but if it is separated it is maybe alright. 
However, I have problems with systems that seem to say "here is nice high-level 
programming", but here's a way to subvert it. Layers and paradigms should be 
kept separate. If one paradigm is cross-bred with another, both paradigms lose 
their meaning and things begin to break down.

> So does any language to somebody with a good debugger.

Yes, there's no problem with knowing the lower level. On B5000 machines I knew 
the runtime well, could pretty much say what machine code any line of ALGOL 
would generate, could find my way around system dumps, far easier than on any 
other machine I have coded on. But did ALGOL ever need the programmer to 
subvert it at an assembler level? No. There WASN'T even an assembler. Thus the 
whole system was a self-contained package and you never needed to subvert the 
paradigm. Now that's a cohesive system. Seems when we need to dig around in 
internals the system is not actually cohesive.

> Don’t think you’re safe if you program in C or C++.

Never. C and C++ are the biggest reason for the sorry state of security we have 
on systems these days. As Bob Barton noted "Systems programmers are the high 
priests of a low cult"

http://www.computer.org/portal/web/csdl/doi/10.1109/MC.1980.1653540


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ObjC's flat and all-exported namespace, help!

[Ian Joyner]

On 10 Nov 2011, at 21:22, Andreas Grosam wrote:

> 
> On Nov 10, 2011, at 2:04 AM, Ian Joyner wrote:
> 
> 
> So, in other words, you prefer "polymorphic runtime resolved" symbols over 
> "compile-time resolved symbols" (like in C++).

Not saying that at all, and don't really agree with that. If a compiler can 
statically analyze things and resolve at compile time, that's good for 
optimization and statically-typed languages can do that. But for full type 
flexibility, we need to defer some cases until run time.
> 
> I just don't understand, why this makes C++ namespace syntax ugly, and why 
> you still state that C++ namespace is inflexible and problematic, and inflict 
> more issues than it solves.

Because this is trying to solve a problem at the programming level that should 
not be at the programming level. It's putting the concern of name clash 
avoidance throughout the code. That's not a good place to solve this problem. 
It's an ugly solution. Eiffel solves these kinds of problems externally to the 
language, so that program code is kept clean.

> While this is not true (IMO), I don't understand what this (and  Windows, C 
> pointers, and gotos, etc.) has to do with a new namespace feature for 
> Objective-C/C++.

Because like badly done gotos, you get this concern interwoven throughout the 
code. That is just not clean code. That's why aspect-oriented programming 
removes certain aspects from the code and uses the technique of weaving to 
automatically put it back in.

C++ does everything the bone-headed way. "We have a problem, so let's solve it 
with another language construct". No programming languages should be kept 
simple and issues of organization kept external.

John Backus has a nice quote in:

http://www.stanford.edu/class/cs242/readings/backus.pdf

"For twenty years programming languages have been steadily progressing toward 
their present condition of obesity; as a result, the study and invention of 
programming languages has lost much of its excitement. Instead, it is now the 
province of those who prefer to work with thick compendia of details rather 
than wrestle with new ideas. Discussions about programming languages often 
resemble medieval debates about the number of angels that can dance on the head 
of a pin instead of exciting contests between fundamentally differing concepts."

Namespaces is just trying to make something else dance on the head of this pin.

> I fear these divagations are contra-productive.

Why? Because someone points out that namespaces are a bad idea and tells you 
why?
> 
> 
>> The programming community needs to learn what the phrase 'separation of 
>> concerns' really means.
> 
> I would certainly agree about some "polymorphic dynamically resolved" 
> namespace feature in Objective-C. I'm awaiting your lecture.

No, I've given enough lectures in the last few days. Undergrads seem to enjoy 
"thinking differently" with heretical ideas and why in a class on software 
project management I'm telling them management is a bad idea and is a doomed 
class!

We really should be in the obj-c newsgroup.

Ian
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Locks

[Ian Joyner]

You are probably looking for something like Dahm locks (invented by Dave Dahm 
on the Burroughs B5000 in the 1960s). Here is a long paper on locks including 
this origin:

http://pages.cs.wisc.edu/~remzi/OSFEP/threads-locks.pdf

Here is an idea of the ALGOL define for acquire:

DEFINE
 ACQUIRELOCK (ID) =
 BEGIN
   IF READLOCK (PROCESSID, CONTENDERS[ID]) ^= 0 THEN
  DO
 PROCURE (LOCKS[ID])
  UNTIL READLOCK (-1, CONTENDERS[ID]) = 0;
   OWNERS  [ID] :=  PROCESSID;
 END #


On 7 Dec 2011, at 10:28, koko wrote:

> In windows we have:
> 
> LONG volatile Mylock = 0;
> InterlockedIncrement(&Mylock);
> InterlockedDecrement(&Mylock);
> 
> 
> What should these be replaced with for OSX  as in :
> 
> #ifndef MAC
> LONG volatile Mylock = 0;
> #else
> // Mac 
> #endif
> 
> 
> void SetLock()
> {
> //EnterCriticalSection(&m_cs);
> #ifndef MAC
>   while(Mylock){Sleep(0);};   // Give up timeslice
>   InterlockedIncrement(&Mylock);
> #else
> // Mac
> #endif
> }
> 
> 
> void FreeLock()
> {
> //LeaveCriticalSection(&m_cs);
> #ifndef MAC
>   InterlockedDecrement(&Mylock);
> #else
> // Mac
> #endif
> }
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Locks

[Ian Joyner]

On 11 Dec 2011, at 01:50, Scott Ribe wrote:

> On Dec 9, 2011, at 4:48 PM, Ian Joyner wrote:
> 
>> You are probably looking for something like Dahm locks (invented by Dave 
>> Dahm on the Burroughs B5000 in the 1960s). Here is a long paper on locks 
>> including this origin:
>> 
>> http://pages.cs.wisc.edu/~remzi/OSFEP/threads-locks.pdf
>> 
>> Here is an idea of the ALGOL define for acquire:
>> 
>> DEFINE
>> ACQUIRELOCK (ID) =
>>BEGIN
>>  IF READLOCK (PROCESSID, CONTENDERS[ID]) ^= 0 THEN
>> DO
>>PROCURE (LOCKS[ID])
>> UNTIL READLOCK (-1, CONTENDERS[ID]) = 0;
>>  OWNERS  [ID] :=  PROCESSID;
>>END #
> 
> I seriously, seriously, seriously doubt that he wants to be implementing 
> locks by translating Algol, *especially* when key, tricky to get correct, 
> routines are not provided.

I doubt that as well and that was not my suggestion or intention or I could 
have posted the whole file and suggested he do that (although that code is very 
old and apparently not in current implementations).

> But then again, based on the Windows code he presented, OP has nothing 
> against re-implementing these functions poorly ;-)
> 
> OSAtomic functions could replace the Interlocked functions. But seriously, 
> what's wrong with the available lock functions? Why in the world would you 
> implement your own locks???

That was the intention to get OS X equivalent and to throw in a bit of 
background and accreditation to Dave Dahm and other visionaries at Burroughs 
who truly thought different or we'd still be coding machine language.

Ian
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Xcode - An Apple Embarrassment

[Ian Joyner]

Another 2c. I had a product called MacEiffel, which brought the Eiffel 
programming language to Mac native development environments, first CodeWarrior 
where it was easy to interface reasonably to CW, but then to ProjectBuilder 
where I couldn't do the neat things I could with CW, but then to Xcode. Xcode 
changed so radically, it really was impossible to keep up, and was even dropped 
for languages like Java.

So one of the factors in letting MacEiffel go was the speed of change of the 
development environment. To run Eiffel on Mac now you have to use EiffelStudio, 
which is really good, but runs under X11, and does not generate the best OS X 
applications.

It would be nice to target languages apart from Objective-C to Xcode, but it is 
too much of a moving target.

Ian

On 2 Mar 2012, at 10:27, Gene Crucean wrote:

> Man I don't know why there is soo much hate towards v4... but I personally
> love it. I think it's one of the best IDE's available on any platform. Yes
> there are bugs... but there are bugs in every IDE. Go try and use Visual
> Studio. Gah.
> 
> To be honest, it seems that the majority of the noise is about a slightly
> different workflow than what is used to from v3. My answer to that is,
> adapt or di... err I mean, or get fired.
> 
> My $0.02 anyway.
> 
> -Gene
> 
> 
> On Thu, Mar 1, 2012 at 6:01 AM, George Toledo  wrote:
> 
>> I'm not sure how/why this has spilled over to the Cocoa list, but out of
>> curiosity Wade, did you work there after Xcode 4's release? If not, I think
>> the argument is slightly specious.
>> 
>> Does anyone require devs at Apple to use Xcode 4, or conform to the broken
>> technologies that are foisted upon outside Developers? I don't know...
>> totally rhetorical, but I'd hope not, because as bad as it is to have this
>> put upon us, I'd hate to think they're using this trash across the board.
>> 
>> -gt
>> 
>>> Message: 4
>>> Date: Wed, 29 Feb 2012 16:41:27 -0800
>>> From: Wade Tregaskis 
>>> To: Matt Neuburg 
>>> Cc: "cocoa-dev@lists.apple.com" ,  Joar
>>>  Wingfors 
>>> Subject: Re: Xcode - An Apple Embarrassment
>>> Message-ID: 
>>> Content-Type: text/plain; CHARSET=US-ASCII
>>> 
 *No*. I've said it before (right here) and I'll say it again; this is
>> *not* jumping to the documentation, and it is *not* doing what Xcode 3 did.
>> It switches to the documentation window and it enters the double-clicked
>> word into the search field, and it does the search, but it doesn't
>> display the actual documentation on the double-clicked word.
>>> 
>>> Indeed, the regressions around this simple piece of functionality are
>> disturbing.  I also find that it rarely handles double clicks correctly.  I
>> have to triple or quadruple-click much of the time.  It's often faster to
>> just bring up the organiser (command-shift-2, obviously) and navigate to
>> the desired docs directly, than play some kind of bizarro skill game with
>> my mouse button.
>>> 
 Once again I put forward my pet wild-and-crazy "dog food" theory that
>> the people at Apple do not actually *use* Xcode for serious work. I know it
>> sounds wild and crazy, but I have two kinds of evidence for this theory:
>>> 
>>> Occam's razor (and my own nearly four years working on developer tools
>> at Apple) will present a different explanation:  Xcode is used exhaustively
>> within Apple, but the Xcode team just aren't good at producing a solid
>> product.  I'm not sure why that is; all the people I know on the Xcode team
>> are very good developers, at least individually.
>>> 
>>> Someone else pretty well hit the nail on the head earlier when they
>> suggested that developer tools just aren't given much top-level interest.
>> I don't know if that can be blamed for the end result though.
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> 
>> https://lists.apple.com/mailman/options/cocoa-dev/emailgeneonthelist%40gmail.com
>> 
>> This email sent to emailgeneonthel...@gmail.com
>> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch.

Re: Carbon is C++?

[Ian Joyner]

Carbon was originally Pascal based, at least as far as the APIs. It does not 
essentially matter what it is written in, just what APIs it supports. If it has 
been rewritten in C++ (are they mad?), that should make no difference to 
whatever developer language is used, and would not be an argument to write in 
C++.

Should you write any high-level applications in C++ - probably not. If you are 
just writing Cocoa apps - don't use it. Just stick to Objective-C.

The idea of Objective-C++ is really to port things from other platforms more 
easily, or perhaps do cross-platform development.

Ian

On 26 Feb 2010, at 10:40, Chunk 1978 wrote:

> is Apple's Carbon basically code written in C++, while Cocoa is
> written in Objective-C?  should developers avoid using frameworks
> written in C++ (like some sound frameworks)?
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iOS: Monospaced fonts aren't?

[Ian Joyner]

On 11 Dec 2010, at 07:16, Murat Konar wrote:

> Maybe CourierNewPS-BoldMT is not a monospaced font?

It sounds like one of those rip-off fonts that have polluted the font space. Is 
plain Courier not available on iOS?

I have some links about fonts from one of my pages (click the 'here' links):

http://www.ianjoyner.name/Ian_Joyner/Fonts.html

> 
> _murat
> 
> On Dec 10, 2010, at 11:39 AM, Phillip Mills wrote:
> 
>> I've been having one of those "I must be doing something stupid" days.  The 
>> code I'm trying to write needs to pad one string with spaces so that certain 
>> characters line up visually with selected characters in a different string 
>> (within a view).  It seemed like a relatively easy task as long as I could 
>> require the use of a monospaced font.  However, it comes out looking various 
>> kinds of wrong depending on how many spaces I add.  I've tried this with a 
>> number of Courier variants with the same result.
>> 
>> The following test seems to confirm that a string of spaces does not render 
>> in the same bounding box as a string of alphanumeric characters or 
>> punctuation marks.  (Also, that there may not be a neat and obvious formula 
>> for how to compensate.)  Are these results reproducible?  Was a fixed-size 
>> character width a bad assumption?  Or is it a bug?
>> 
>> - (void)debugFont {
>>  UIFont *font = [UIFont fontWithName:@"CourierNewPS-BoldMT" size:24];
>>  
>>  // With 22 characters, there's a width difference of 9
>>  NSString *s1 = @"1234567890123456789012";
>>  NSString *s2 = @"  ";
>>  
>>  // The choice of non-space character doesn't seem to matter
>>  NSString *s5 = @"..";
>>  
>>  // With 23 characters, there's a width difference of 10
>>  NSString *s3 = @"12345678901234567890123";
>>  NSString *s4 = @"   ";
>>  
>>  NSLog(@"@. size: %f", s1, [s1 sizeWithFont:font].width);
>>  NSLog(@"@. size: %f", s2, [s2 sizeWithFont:font].width);
>>  NSLog(@"@. size: %f", s5, [s5 sizeWithFont:font].width);
>>  NSLog(@"@. size: %f", s3, [s3 sizeWithFont:font].width);
>>  NSLog(@"@. size: %f", s4, [s4 sizeWithFont:font].width);
>> }
>> 
>> 2010-12-10 14:19:03.936 FontTest[1834:207] .1234567890123456789012. size: 
>> 317.00
>> 2010-12-10 14:19:03.937 FontTest[1834:207] .  . size: 
>> 308.00
>> 2010-12-10 14:19:03.938 FontTest[1834:207]  size: 
>> 317.00
>> 2010-12-10 14:19:03.938 FontTest[1834:207] .12345678901234567890123. size: 
>> 332.00
>> 2010-12-10 14:19:03.939 FontTest[1834:207] .   . size: 
>> 322.00
>> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iOS: Monospaced fonts aren't?

[Ian Joyner]

On 11 Dec 2010, at 11:02, Phillip Mills wrote:

> On 2010-12-10, at 5:38 PM, Ian Joyner wrote:
> 
>> Is plain Courier not available on iOS?
> 
> Courier is there but with the same problem.

How about other monospaced fonts? Monaco is the only other common one I can 
think of (or Andale Mono):

http://en.wikipedia.org/wiki/Samples_of_monospaced_typefaces

Do you have any italics? Strange characters you can boil it down to?

Still begs the question as to what are the official sanctioned/recommended 
fonts?

Ian
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iOS: Monospaced fonts aren't?

[Ian Joyner]

I just heard an interesting program on "Fighting for Authentic Design":

http://www.abc.net.au/rn/bydesign/stories/2010/3087247.htm

Some of the links on my page were broken. Does anyone know what has happened to 
the excellent screenfonts.ca site?

I have also added Courier to Courier New comparison.

While font issues aren't exactly specific to Cocoa, this is an issue that 
should be much more widely known about, especially among developers. But I also 
have the question about which fonts are officially sanctioned by Apple to use?

Ian

On 11 Dec 2010, at 09:38, Ian Joyner wrote:

> On 11 Dec 2010, at 07:16, Murat Konar wrote:
> 
>> Maybe CourierNewPS-BoldMT is not a monospaced font?
> 
> It sounds like one of those rip-off fonts that have polluted the font space. 
> Is plain Courier not available on iOS?
> 
> I have some links about fonts from one of my pages (click the 'here' links):
> 
> http://www.ianjoyner.name/Ian_Joyner/Fonts.html
> 
>> 
>> _murat
>> 
>> On Dec 10, 2010, at 11:39 AM, Phillip Mills wrote:
>> 
>>> I've been having one of those "I must be doing something stupid" days.  The 
>>> code I'm trying to write needs to pad one string with spaces so that 
>>> certain characters line up visually with selected characters in a different 
>>> string (within a view).  It seemed like a relatively easy task as long as I 
>>> could require the use of a monospaced font.  However, it comes out looking 
>>> various kinds of wrong depending on how many spaces I add.  I've tried this 
>>> with a number of Courier variants with the same result.
>>> 
>>> The following test seems to confirm that a string of spaces does not render 
>>> in the same bounding box as a string of alphanumeric characters or 
>>> punctuation marks.  (Also, that there may not be a neat and obvious formula 
>>> for how to compensate.)  Are these results reproducible?  Was a fixed-size 
>>> character width a bad assumption?  Or is it a bug?
>>> 
>>> - (void)debugFont {
>>> UIFont *font = [UIFont fontWithName:@"CourierNewPS-BoldMT" size:24];
>>> 
>>> // With 22 characters, there's a width difference of 9
>>> NSString *s1 = @"1234567890123456789012";
>>> NSString *s2 = @"  ";
>>> 
>>> // The choice of non-space character doesn't seem to matter
>>> NSString *s5 = @"..";
>>> 
>>> // With 23 characters, there's a width difference of 10
>>> NSString *s3 = @"12345678901234567890123";
>>> NSString *s4 = @"   ";
>>> 
>>> NSLog(@"@. size: %f", s1, [s1 sizeWithFont:font].width);
>>> NSLog(@"@. size: %f", s2, [s2 sizeWithFont:font].width);
>>> NSLog(@"@. size: %f", s5, [s5 sizeWithFont:font].width);
>>> NSLog(@"@. size: %f", s3, [s3 sizeWithFont:font].width);
>>> NSLog(@"@. size: %f", s4, [s4 sizeWithFont:font].width);
>>> }
>>> 
>>> 2010-12-10 14:19:03.936 FontTest[1834:207] .1234567890123456789012. size: 
>>> 317.00
>>> 2010-12-10 14:19:03.937 FontTest[1834:207] .  . size: 
>>> 308.00
>>> 2010-12-10 14:19:03.938 FontTest[1834:207]  size: 
>>> 317.00
>>> 2010-12-10 14:19:03.938 FontTest[1834:207] .12345678901234567890123. size: 
>>> 332.00
>>> 2010-12-10 14:19:03.939 FontTest[1834:207] .   . size: 
>>> 322.00
>>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: strategies for working w/ large amounts of text

[Ian Joyner]

On 13 Dec 2010, at 14:03, Shane wrote:

>> Are you building a concordance database first ?
>> 
> 
> I have no thoughts whatsoever on how I'm building anything as of yet.
> Just researching how something of this size would be manipulated.

In the case of large texts like the Bible, you have a data source that is 
pretty much static. That is, if you put it in a database you won't run update 
operations against it.

The big question is, if you go to the trouble of breaking it into database 
records - maybe one per verse, what does that get you. Even putting it into XML 
might be a lot of work, and what happens when the next technology comes along.

Text is fairly flexible and searchable. You don't actually need a concordance 
(index). Searching through text is pretty fast (probably a modern processor 
will have found all occurrences of the word 'the' before you have got the 
concordance off the shelf. Spotlight technology could also help there to 
generate an index for you.

That said, what can you do with Cocoa? Why don't you model what you want in 
Core Data. That is data store agnostic so you could use a database (SQLite) or 
XML later. Once you have a model, this might help you see potential 
applications.

Having said that, I believe we are at the beginning of rearranging many linear 
texts into more immediately and easily useful forms, particularly teaching 
texts.

Ian
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why so many public properties all up in my grizzle?

[Ian Joyner]

This is an interesting discussion, but there is a lot of misunderstanding of 
the concept of information hiding if not in what has been said here, but 
generally in the industry. This term was introduced by David Parnas, and I 
think it is a bit unfortunate because if you read his papers on this he really 
means implementation hiding:

On the Criteria to be used in Decomposing Systems into Modules (1972):

http://www-sst.informatik.tu-cottbus.de/~db/doc/People/Broy/Software-Pioneers/Parnas_hist.pdf

The Secret History of Information Hiding (2002):

http://www-sst.informatik.tu-cottbus.de/~db/doc/People/Broy/Software-Pioneers/Parnas_new.pdf

There is something deeper to this than simply hiding variables. A lot of people 
using C++, Java, etc think it means hiding data behind get and set routines. 
However, in reality we are trying to expose data, we are just trying to do it 
in an implementation independent manner. Thus it is the interface (API) is the 
important part of the design.

A corollary of this is Bertrand Meyer's Principle of Uniform Access, which says 
values should be provided to a caller in a uniform way, no matter whether the 
data comes from storage (variable), is computed either in an expression or a 
function:

http://en.wikipedia.org/wiki/Uniform_access_principle

http://martinfowler.com/bliki/UniformAccessPrinciple.html

I think Martin Fowler's article clearly shows Parnas's ideas.

Objective-C implements this principle of uniform access with properties.

Ian

On 17 Mar 2012, at 08:56, Conrad Shultz wrote:

> On 3/16/12 2:00 PM, Brian Lambert wrote:
>> This means that my UILabel called labelMyLabel is publicly available.
>> Anyone who has access to an instance of MyViewController can do anything
>> they want to with my label, including replacing it.
>> 
>> Also, anyone who has an instance of MyViewController can call my
>> buttonDoItTouchUpInside action.
> 
> In addition to David's remarks, it should also be noted that there isn't
> really any concept of "private" properties or methods (in the enforced
> sense) in Objective-C due to the dynamic nature of the language and
> runtime.  No matter where you *declare* your properties and/or methods,
> what you state above would always be possible.
> 
> (As an aside, major features in Cocoa rely on fairly crazy runtime
> manipulation.  For example, key-value observing:
> http://mikeash.com/pyblog/friday-qa-2009-01-23.html)
> 
> Suppose you wanted to peek under a class' hood (for curiosity's sake, of
> course; private API usage is generally a bad idea and is explicitly
> forbidden in the App Stores and from discussion on the official mailing
> lists).  To see a class' properties (both from itself and its protocols)
> you could try something along the lines of (warning: a thrown together
> quick hack, probably has bugs):
> 
>unsigned int propertyCount;
>objc_property_t *allProperties = class_copyPropertyList([MyClassName
> class], &propertyCount);
>for (NSUInteger i = 0; i < propertyCount; i++) {
>const char *name = property_getName(allProperties[i]);
>NSLog(@"%s", name);
>}
> 
>unsigned int protocolCount;
>Protocol **allProtocols = class_copyProtocolList([MyClassName
> class], &protocolCount);
>for (NSUInteger i = 0; i < protocolCount; i++) {
>const char *protocol = protocol_getName(allProtocols[i]);
>NSLog(@"PROTOCOL %s", protocol);
>unsigned int protoPropertyCount;
>objc_property_t *protoProperties =
> protocol_copyPropertyList(allProtocols[i], &protoPropertyCount);
>for (NSUInteger j = 0; j < protoPropertyCount; j++) {
>const char *propName = property_getName(protoProperties[j]);
>NSLog(@"\t%s", propName);
>}
>}
> 
> This and other fun hackery is documented in the Runtime Programming
> Guide:
> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide
> 
> 
> 
> -- 
> Conrad Shultz
> 
> Synthetiq Solutions
> www.synthetiqsolutions.com
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: const correctness

[Ian Joyner]

I think you've nailed it. Immutability is certainly a good concept, but 
including ideas from C++ is not a good idea because concepts are usually 
perverted in C++ (and even C - ALGOL carefully removed the junk out of FORTRAN 
and assembler but C, just put that garbage back in.) Concepts need very careful 
understanding of how they interact with the rest of a language before putting 
them in. With C pointers, you can just about subvert any good practice (even 
any good practice that got put in C++).

If people haven't seen this series, Douglas Crockford has a series on 
Javascript (ugh, I know, off topic..., don't tune out, please read on):

http://net.tutsplus.com/tutorials/javascript-ajax/crockford-on-javascript-the-complete-series/

which is about far more than just Javascript. It is about why programmers are 
resistant to new ideas, how we usually end up with messes (JS in particular), 
language design, and subtly why C and C++ are poor languages. Oh, yeah, and why 
the web is such a mess (just bad ideas done quickly and a great perspective on 
the lasting effect of the browser wars). This series is well worth watching for 
the insights it has into our profession.

Ian

On 19 Mar 2012, at 05:39, Jens Alfke wrote:

> 
> On Mar 18, 2012, at 11:01 AM, Luther Baker wrote:
> 
>> Obj-C and Cocoa don't support "const" because they are older?
> 
> More because they weren’t designed around it. And because the way C++ does 
> ‘const’ gets really problematic in a dynamic OOP language like Obj-C.
> 
> Say you added ‘const’ object pointers to Obj-C. The direct meaning is that 
> the caller isn’t allowed to modify instance variables through a const 
> pointer. But touching another object’s ivars is almost unheard-of in Obj-C. 
> So the significant meaning would be that the only methods you can call on 
> such a pointer are those declared ‘const’; and inside a method declared 
> ‘const’, ‘self’ is a const pointer, so the method isn’t allowed to modify 
> instance variables. So far so good.
> 
> The problem is how you declare a method as const. In Objective-C method names 
> aren’t tightly bound to classes; they’re selectors and they exist 
> independently. So different classes might implement methods with the same 
> selector even though they aren’t related to each other, and you can send a 
> message to an object using a particular selector without knowing what class 
> of object it is (if the pointer is typed as ‘id’, or if you’re calling 
> something like -performSelector:.)
> 
> So things would start to get really messy if two unrelated classes 
> implemented the same method name (i.e. same selector) but one made it const 
> and one didn’t. Now if you send that message to an ‘id’ variable, the 
> compiler doesn’t know whether it’s const or not and whether to allow or deny 
> the call.
> 
> Anyway. This is digressing, and probably belongs on the objc-language list if 
> anyone wants to pursue it further. My guess is it isn’t worth pursuing, 
> because Obj-C already has a different mechanism for handling mutable vs 
> immutable state, and it works very differently (it’s the objects that are 
> mutable/immutable, not just the pointers thereto), and trying to add in the 
> C++ notion would probably be very ugly even if it could be done.
> 
> —Jens
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: const correctness

[Ian Joyner]

On 19 Mar 2012, at 09:31, Shawn Bakhtiar wrote:

> "...subtly why C and C++ are poor languages..."
> 
> 1) Is that why most modern operating systems, especially the ones that run in 
> data centers are written in C?
> 
Popularity is more a proof of mass stupidity rather than quality. The cult of C 
followed on from what Bob Barton called the cult of FORTRAN in 1963 and also 
noted that systems programmers are high priests of a low cult.

> 2) Isn't Objective-"C" a supper set of C, so does that make Objective-C a bad 
> language as well?

Unfortunately OC is C-based, but it changed C in a completely different way to 
C++ in a way that OC is almost a decent language, in fact the best dialect of C 
that exists.
> 
> Isn't Mutability just another word for constant-ability?

No, that's immutability. C it's already confusing talking about things in see 
:-)
> 
> I hate to use Wiki for citation but:
> 
> http://en.wikipedia.org/wiki/Const-correctness
> 
> "In computer science, const-correctness is the form of program correctness 
> that deals with the proper declaration of objects as mutable or immutable. 
> The term is mostly used in a C or C++ context, and takes its name from the 
> const keyword in those languages."

Well, it's more instructive to follow the link to immutable objects.
> 
> Doesn't const void ** = NSMutableArray in meaning,

Actually NSArray. Note NSMutableArray inherits from NSArray because it adds 
extra functionality in methods that can change the object. You can assign an 
NSMutableArray object to an NSArray reference, thereby making it unchangeable 
via that path, but you can't assign an NSArray object to an NSMutableArray.

> with the first being a simple way for the programmer to avoid clobbering data 
> that SHOULD not be changed, and the latter being a compiler enforced one?

Well, const void ** (what gobbledegook, let me get my head around it), means 
you cannot change the pointed to objects (haven't they got the message C 
pointers are bad) via that pointer. An NSArray reference to an NSArray object 
means you can't change that object, ever vs., an NSArray reference (note 
references are different to pointers) to an NSMutableArray means you can't 
change the NSMutableArray via that reference. As already said you can't have an 
NSMutableArray reference to an NSArray object.

Still suggest watching Crockford where he traces C's ancestry to ALGOL with the 
junk from FORTRAN and assembler put back in, the junk the ALGOL people (many of 
whom had previously designed FORTRAN, like Backus) had deliberately left out. 
An extension of ALGOL then brought us OO – Simula. Crockford also advises on 
how to avoid the bad parts of JavaScript, a lesson we need in avoiding the bad 
parts of C. C has more to do with assembler programming than HLL and structured 
programming. You don't need assembler to write operating systems - I'd hardly 
call them modern. (The only truly modern OS I can think of actually predates 
them all.)
> 
> 
> 
> 
>> Subject: Re: const correctness
>> From: ianjoy...@me.com
>> Date: Mon, 19 Mar 2012 09:16:52 +1100
>> To: Cocoa-dev@lists.apple.com
>> 
>> I think you've nailed it. Immutability is certainly a good concept, but 
>> including ideas from C++ is not a good idea because concepts are usually 
>> perverted in C++ (and even C - ALGOL carefully removed the junk out of 
>> FORTRAN and assembler but C, just put that garbage back in.) Concepts need 
>> very careful understanding of how they interact with the rest of a language 
>> before putting them in. With C pointers, you can just about subvert any good 
>> practice (even any good practice that got put in C++).
>> 
>> If people haven't seen this series, Douglas Crockford has a series on 
>> Javascript (ugh, I know, off topic..., don't tune out, please read on):
>> 
>> http://net.tutsplus.com/tutorials/javascript-ajax/crockford-on-javascript-the-complete-series/
>> 
>> which is about far more than just Javascript. It is about why programmers 
>> are resistant to new ideas, how we usually end up with messes (JS in 
>> particular), language design, and subtly why C and C++ are poor languages. 
>> Oh, yeah, and why the web is such a mess (just bad ideas done quickly and a 
>> great perspective on the lasting effect of the browser wars). This series is 
>> well worth watching for the insights it has into our profession.
>> 
>> Ian
>> 
>> On 19 Mar 2012, at 05:39, Jens Alfke wrote:
>> 
>>> 
>>> On Mar 18, 2012, at 11:01 AM, Luther Baker wrote:
>>> 
 Obj-C and Cocoa don't support "const" because they are older?
>>> 
>>> More because they weren’t designed around it. And because the way C++ does 
>>> ‘const’ gets really problematic in a dynamic OOP language like Obj-C.
>>> 
>>> Say you added ‘const’ object pointers to Obj-C. The direct meaning is that 
>>> the caller isn’t allowed to modify instance variables through a const 
>>> pointer. But touching another object’s ivars is almost unheard-of in Obj-C. 
>>> So the significant

Re: const correctness

[Ian Joyner]

On 20 Mar 2012, at 02:43, Nick Zitzmann wrote:

> On Mar 19, 2012, at 5:51 AM, Ian Joyner wrote:
> 
>> Actually NSArray. Note NSMutableArray inherits from NSArray because it adds 
>> extra functionality in methods that can change the object. You can assign an 
>> NSMutableArray object to an NSArray reference, thereby making it 
>> unchangeable via that path, but you can't assign an NSArray object to an 
>> NSMutableArray.
> 
> Declaring an NSMutableArray as an NSArray doesn't make it immutable, because 
> you can still send NSMutableArray messages to the array and they'll still 
> work (though the compiler will complain unless you mask them or send the 
> message indirectly). The only way to make a mutable array immutable is to 
> make an immutable copy of the array.

I think we agree. The point is that we have two types involved, the type of the 
object itself and the type of the pathway to it (reference). That's why you 
should not (and cannot I hope) assign an NSArray (immutable) object to an 
NSMutableArray. The general case is that you cannot assign an object of a 
supertype to a reference to a subtype, because then you can do inappropriate 
things to the object.

The interesting case is when you have a supertype reference to an object of a 
subtype and then try assigning that object back to a reference of the same 
subtype. This is a legitimate case, but type systems would usually preclude it, 
which is why those who like dynamic typing don't like static typing. But this 
case can be handled in a typed language. Eiffel calls it the assignment 
attempt, which happens at run time by ensuring that the actual run time type of 
an object conforms to the type of the reference, else the reference is just set 
to nothing.

Ian
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: const correctness

[Ian Joyner]

Really const correctness in the first place belonged in the Objective-C group.


If you read the rest of my post I'm talking about immutability and const 
correctness, so although this comment on popularity came first it was just a 
subtopic and you have picked on this as a sub topic of the post rather than the 
meat in the rest of it. Perhaps if I'd made a point about Windows and mass 
stupidity it would have been better.


Really, what I am concerned about is the thought that we should add things to 
Obj-C just because C++ has it. Language features require much more thought than 
that. While all the flaws of C are necessarily preserved in Obj-C, Obj-C 
defines a much more disciplined use of the language. Almost all of the bad 
features are avoided in normal practice and an OC programmer almost has to go 
out of their way to use the garbage. That's one of the staggeringly good things 
about OC as designed by Brad Cox and adapted by NeXT/Apple. C++ is just one of 
the biggest messes in the programming world. Why? Complexity, complexity, 
complexity.

I mentioned the Crockford series for three reasons - 1) his thesis that 
programmers have always been resistant to better things; 2) his showing how to 
avoid deficiencies in a language (the example is JavaScript); 3) how most 
deficiencies in JavaScript actually come from C (via Java in some cases) and 
how C had bad things included from FORTRAN and assembler that should not have 
been (because of (1)).

In the context of security, Crockford makes the point that complexity is the 
tool of the enemy. With simplicity we can solve the problems. So my concern 
with the way this thread was going was that it became "Let's just add the 
complexity of C++ into OC." That is not healthy and if followed could destroy 
the relative simplicity and power of OC.

Crockford is a very friendly and subtle speaker, but pulls no punches about the 
state of the Web and why most of it is rubbish, filled with security holes, 
etc. He has so many lessons on so many levels and I recommend it to the Cocoa 
community, even though not directly Cocoa related, but his thinking is relevant 
to so many things and most of us have to be involved in the web in one way or 
the other.

Thanks
Ian

P.S sounds like you still need to go and study up some material on the B5000 to 
see how a really elegant design of 50 years ago is still way ahead of its time 
and would solve many of the security and other problems of today. I apologize 
if I have helped close your mind to this.

http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/Organick_B5700_B6700_1973.pdf
Stories of the B5000 and People Who Were There

On 20 Mar 2012, at 02:55, Jens Alfke wrote:

> 
> On Mar 19, 2012, at 4:51 AM, Ian Joyner wrote:
> 
> 
> Please take this off-list, or to some more appropriate list (I think it’s 
> already deep-ended past objc-language; is there an algol-like-language list?) 
> Otherwise we’ll be hearing about the Burroughs B500 soon, and I don’t think I 
> can take that again.
> 
> I don’t mean to be rude, but I’m about at my personal limit of patience with 
> the amount of off-topic stuff one has to wade through on the Apple lists 
> lately (especially xcode-users, but here too.) I’m not a moderator and I’m 
> not here as part of my job description; I hang out when I have time to and 
> mostly try to answer questions to help people out. If the list gets too noisy 
> I tend to give up and ignore it for weeks or months before coming back. I’m 
> sure there are other experienced people here who do the same. It’s to 
> everyone’s benefit if the list stays on topic so that people who need help 
> can get it and people who want to offer help can give it.
> 
> —Jens

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Displaying "Trebuchet MS" font

[Ian Joyner]

On 14 May 2013, at 04:37, Appa Rao Mulpuri  wrote:

> Any specific reason not to use "Trebuchet MS"?  I faced some issues with the 
> few components (ilke Table Header cell, NS Button) text vertical center 
> alignment except that Look and feel wise its equivalent to "Lucida Grande". 
> And also both the fonts is taking the equal size for the same text.

Yes there is now a confusion of very similar fonts. Many were done by Microsoft 
with tweaks to original fonts made to make them look 'good' (in someone's 
opinion, or was it just marketing) on the computer screens of the 1990s. This 
shows the MS philosophy of bending the natural world to suit their technology, 
not improving technology to suit the world. So they designed fonts to look good 
on crappy screens. Apple on the other hand came along and said "we like these 
beautiful fonts, we don't want to change them, so let's make the screens 
better".

Another reason MS designed all these wacky fonts was licence fees. While 
bleating on about people stealing software with copies and depriving them of 
fees, they copied fonts, subtly changing a few pixels and the name to avoid 
licence fees.

Arial it should be noted is just Helvetica, but you will notice some of the 
tops of letters are sloped instead of straight, actually making Arial less 
readable. Arial is now everywhere, it's a horrible font:

http://www.marksimonson.com/notebook/view/the-scourge-of-arial

There was another site screenfont.ca but it seems to have disappeared. I 
suspect trebuchet (a medieval catapult) is in the same category, and is a font, 
like Arial that will take years to kill off.

We need to put font design back into the hands of artists, not technical 
people... or artists (like Matthew Carter) constrained by technologists.

> 
> - Apparao
> 
> From: Jens Alfke mailto:j...@mooseyard.com>>
> Date: Mon, 13 May 2013 10:35:33 -0700
> To: Apparao mailto:appar...@ivycomptech.com>>
> Cc: "cocoa-dev@lists.apple.com" 
> mailto:cocoa-dev@lists.apple.com>>
> Subject: Re: Displaying "Trebuchet MS" font
> 
> 
> On May 13, 2013, at 7:07 AM, Appa Rao Mulpuri 
> mailto:appar...@ivycomptech.com>> wrote:
> 
> I am working on an application which will display Same font (Trebuchet MS) 
> throughout the Application. I have changed in all places except the following 
> ones
> 
> Window Tool bar items text
> Text in NSAlert panels
> Tooltip text
> 
> Please don’t do this. Unless you actually want your app to look like a 
> careless port, and give lots of people a bad first impression of it.
> 
> —Jens
> This email and any attachments are confidential, and may be legally 
> privileged and protected by copyright. If you are not the intended recipient 
> dissemination or copying of this email is prohibited. If you have received 
> this in error, please notify the sender by replying by email and then delete 
> the email completely from your system. Any views or opinions are solely those 
> of the sender. This communication is not intended to form a binding contract 
> unless expressly indicated to the contrary and properly authorised. Any 
> actions taken on the basis of this email are at the recipient's own risk.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Displaying "Trebuchet MS" font

[Ian Joyner]

Thanks for the clarifications Jens, but I don't think what I was saying is so 
far removed from your more detailed story. I did realise after I posted that MS 
probably was somewhat justified in avoiding Adobe's outrageous licence fees. 
And it is certainly true that Matthew Carter is highly regarded and made good 
contributions. Perhaps my concerns are about the careless ways people use fonts 
and just lazily use Arial by default (when they should use a serif font). I 
think there is something of a war between Monotype and Linotype, so this seems 
to have blurred the situation somewhat. Although designed by Carter, I don't 
really like Georgia or Verdana (too wide and blocky), and I think he has done 
better. But like Arial they seem to just be everywhere because too many people 
just do what MS says.

I do think we now have too many fonts and many of these have been designed 
around technological constraints that are disappearing, but they will continue 
to be used by default. I'm continually researching for good fonts and what 
should be used where (a taste I got while working in music publishing, also in 
the late 80s).

So if you have any suggestions of good resource sites making such 
recommendations please pass them on. The many books on typography I have don't 
actually make this very clear.

Ian

On 15 May 2013, at 05:46, Jens Alfke  wrote:

> 
> On May 13, 2013, at 6:43 PM, Ian Joyner  wrote:
> 
>> Yes there is now a confusion of very similar fonts. Many were done by 
>> Microsoft with tweaks to original fonts made to make them look 'good' (in 
>> someone's opinion, or was it just marketing) on the computer screens of the 
>> 1990s. 
> 
> Most of what you say in this email is simply not true. (Watch out, I worked 
> in font technology in the late ‘80s through 1990, and have kept tabs on it 
> since.)
> 
> The initial fonts in Windows were existing ones licensed from Bitstream, 
> including Arial (which is indeed a legal knockoff of Helvetica; for some 
> weird reason typeface designs are not protected by copyright law.) I’m not 
> sure why they went with these instead of getting the originals from Linotype 
> the way Adobe did; cost was probably a factor, also Bitstream had a lot of 
> font technology that Microsoft would have needed at the time.
> 
>> This shows the MS philosophy of bending the natural world to suit their 
>> technology, not improving technology to suit the world. So they designed 
>> fonts to look good on crappy screens. Apple on the other hand came along and 
>> said "we like these beautiful fonts, we don't want to change them, so let's 
>> make the screens better”.
> 
> Um, no. Everyone worked on adjusting fonts to crappy screens and 
> low-resolution printers. “Hinting” was one of the hardest parts of font 
> technology; Adobe tried to keep their algorithms in PostScript proprietary, 
> forcing people to buy very expensive licenses, until Apple did an end-run 
> around it by developing TrueType which had its own hinting scheme.
> 
> In the 1990s you simply could not get away with rendering unhinted fonts, 
> because most people’s displays didn’t support enough color depth to use 
> antialiasing. OS X 10.0 made a break with the past by requiring 16-bit or 
> higher color depth, in part because that was necessary for good antialiased 
> text.
> 
> Another factor that allowed good-looking antialiased unhinted text was 
> sub-pixel antialiasing, aka ClearType, invented by … Microsoft.
> 
>> Another reason MS designed all these wacky fonts was licence fees. While 
>> bleating on about people stealing software with copies and depriving them of 
>> fees, they copied fonts, subtly changing a few pixels and the name to avoid 
>> licence fees.
> 
> Bitstream did that, not Microsoft, back in the ‘70s and ‘80s. They’re far 
> from the only ones who did: other big vendors like Compugraphic made 
> knock-off fonts too, and it goes on today — any of those CD-ROMs with 
> zillions of cheap fonts are loaded with badly-drawn imitations of famous 
> designs.
> 
> Microsoft has since developed/published a lot of original high-quality fonts 
> including Georgia, Verdana, Trebuchet, Calibri, etc. Most of these were 
> designed by very competent highly-regarded type designers like Matthew 
> Carter. Yes, they were designed to look good on low-resolution computer 
> screens with hinting. There’s nothing wrong with that — type has always been 
> designed around the limitations of printing/display technology. Newspaper 
> fonts like Times Roman are specially tweaked to be legible at small sizes on 
> crappy newsprint. Older fonts had tweaks like “ink traps” to work around the 
> way that ink smears around the edge of the glyph dur

Re: NSMapTable with C strings as keys

[Ian Joyner]

On 29 May 2013, at 14:14, Oleg Krupnov  wrote:

> While I generally agree that premature optimization is evil,

That seems to come out of a belief that well-structured code is code that runs 
poorly (this belief came out of an IBM system of the 50s/60s that had really 
poorly running subroutine calls - so the recommendation was not to structure 
things).

In one sense I think we should always be optimizing code. That is in the sense 
that we write well structured and correct code. Usually optimization naturally 
follows. There seems to be a school of thought that writing poorly structured 
code must be optimized, but I have usually seen that most badly running code is 
a result of poor structure and refactoring makes it both structured and 
optimized. Once you have got to such a structured state then you might be able 
to see where further optimizations can be made to profiled areas of code which 
might result in more complex, but still structured and optimized. Where 
something simple is replaced by a more complex algorithm it should be well 
documented.

That is the subject of Dijkstra's book "A Discipline of Programming". Once a 
well-structured algorithm is developed, better optimizations can then be seen. 
This is the 'engineering' part of software development - making software run 
practically (not the drawing diagrams part). For particular computations (that 
is where the algorithm works on particular data sets), an algorithm might not 
be optimal, so needs to cater to those cases.

In summary - we should be producing well-structured code early on. This will 
usually result in well-optimized code. However, this is not a guarantee and 
particular cases may need to be addressed later (that is the premature 
optimization case). But we should always aim to produce well-structured code.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSMapTable with C strings as keys

[Ian Joyner]

On 30 May 2013, at 12:33, Jens Alfke  wrote:
> 
> On May 29, 2013, at 6:30 PM, Ian Joyner  wrote:
> 
>> That seems to come out of a belief that well-structured code is code that 
>> runs poorly
> 
> No, it’s a paraphrase of a famous quote by Don Knuth ("We should forget about 
> small efficiencies, say about 97% of the time: premature optimization is the 
> root of all evil.”[1]) He later attributed this to C.A.R. Hoare.

OK, thanks, it was badly put on my part. I have Knuth's paper and will give it 
another read (after rereading Structured Programming (Dahl, Dijkstra, Hoare) 
which Knuth says will change your life).

What I am trying to point out though is that there is a misapprehension that 
premature optimization means writing structured code early on so don't 
structure it because you can always go and clean it up later. Rather I think we 
should write well-structured code as we go. Often that will result in efficient 
code (invariant statements not being in loops, etc), but that is not what is 
meant by premature optimization.

This kind of optimization is more about changing the algorithm than the code. 
We should beware not to lump well-structured code writing with premature 
optimization just because well-structured code usually ends up being optimized 
code. Well-structured code also ends up being more correct and more easily 
changed and refactored.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSMapTable with C strings as keys

[Ian Joyner]

On 31 May 2013, at 01:43, Jens Alfke  wrote:
> 
> On May 30, 2013, at 3:52 AM, Ian Joyner  wrote:
> 
>> What I am trying to point out though is that there is a misapprehension that 
>> premature optimization means writing structured code early on so don't 
>> structure it because you can always go and clean it up later. Rather I think 
>> we should write well-structured code as we go.
> 
> I agree 100% with that. Structured code is easier to benchmark and optimize 
> later on, anyway — as I said, if you repeat a piece of code ten times, none 
> of the ten instances may show up individually as hot spots, whereas if you 
> called a common function/method in ten places, it may show up and then be 
> easy to fix.
> 
> I would add, though, that the perfect structure (class hierarchy, API, 
> factoring…) may not be apparent right away, especially since you’ll often end 
> up refactoring as you go along. So trying too hard to structure code as 
> you’re initially writing it can end up being a rathole.

Absolutely. It's often the case that we try to get everything ultra-structured 
before writing any code. This can be a writer's block. We often have to use the 
process of coding as an exploratory process. That is the very essence of 
software. It also means that software can be refined as we go. But often we 
need to know when to stop.

Structured (and OO) languages directly support the paradigms. This seems not 
well understood since we attempt to structure code (code is a term I don't 
like) by the use of diagrams because we treat the act of programming as 
translating this into a machine-oriented artefact. But in fact a text-based 
programming language is often more malleable than such diagrams (in terms of 
both tool and mental attitudes that a diagram is fixed, even if a programmer 
comes up with better designs).
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why is it wrong to have relationships without an inverse in Core Data?

[Ian Joyner]

On 23 Jun 2013, at 13:32, "Reaves, Timothy"  
wrote:

> What the docs state that is meaningless (although inaccurate); the
> Objectice-C manual could very easily state that Objective-C is not a
> programing language; it is.  CoreData is a database.

OK, what the Apple doc 
http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/CoreData/Articles/cdTechnologyOverview.html%23//apple_ref/doc/uid/TP40009296-SW1
 says:

"Core Data is not a relational database or a relational database management 
system (RDBMS).

"Core Data provides an infrastructure for change management and for saving 
objects to and retrieving them from storage. It can use SQLite as one of its 
persistent store types. It is not, though, in and of itself a database"

I agree with you in the general sense, but I think the docs are speaking in the 
more specific sense. CoreData is really the middleman which can interface to a 
number of data stores. To think of a database as a data store is also 
misleading because the relational model is very high-level and very abstract 
and about as far away from data store as you could get.

CoreData is more a modelling system (I could say data model... but it's not 
that either). Thus programmers should be abstracted away from the physical 
storage medium (which I think is a point you are making).

However, CD does rather look like the entity-relationship model, which is 
fundamentally broken by distinguishing between entities and relationships and 
lacks precision and formality (correctness and flexibility) which the 
relational model has.

So in one sense you are right it is a database, but I'd say more a definer of 
data models and these happen to get stored somewhere in a database. But CD is 
not that database itself - it is the glue between the DB (or in-memory store) 
and an application program.

>  A database need never
> write anything to a file.  There are - in fact - several examples, of all
> manor, of in-memeory data bases that never bother to persist to a file.  As
> the documentation points out, there are five(?)(XML, plist, SQLite, iCould,
> in-memory) supported backing stores.  Four will cause a file to be created,
> and one will not.
> 
> Yes, it's fully possible for CoreData to be broken into two components; one
> that manages object graphs, and one that manages persisting them.  But
> until that time, CoreData is a framework/library/module with the intention
> of causing data to be stored, even if only in memory. That, by definition,
> makes it a database, and when at least one particular backing stores is
> used, it also makes it an ORM.  That it can do other things is irrelevant.
> 
> Now, enough with the philosophy!  :-D
> 
> 
> 
> 
> 
> On Sat, Jun 22, 2013 at 4:19 PM, Luther Baker  wrote:
> 
>> ... yes, and if you are going to be pedantic, please be somehow consistent
>> with the docs:
>> 
>>> Core Data provides an infrastructure for change management and for
>> saving objects to and retrieving them from storage. It can use SQLite as
>> one of its persistent store types. *It is not, though, in and of itself a
>> database.* (To emphasize this point: you could for example use just an
>> in-memory store in your application. You could use Core Data for change
>> tracking and management, but never actually save any data in a file.)
>> 
>> 
>> http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/CoreData/Articles/cdTechnologyOverview.html#//apple_ref/doc/uid/TP40009296-SW1
>> 
>> 
>> 
>> 
>> On Sat, Jun 22, 2013 at 1:26 PM, Timothy Reaves <
>> trea...@silverfieldstech.com> wrote:
>> 
>>> Yes, CoreData is a database, and it does do ORM.  It's not just an ORM,
>>> and it's not an RDBMS.
>>> 
>>> If it wasn't a database, it couldn't store data; that is the definition
>>> of a database. A database is not something that has row, columns, etc; it's
>>> something that stores data in an unspecified manor.  Yes, and ASCII file
>>> can be a database, as many, many are on the mainframe.  You seem to be
>>> confused as to what a database is.
>>> 
>>> If CoreData didn't do ORM, it couldn't persist objects into a SQL
>>> database, which it does with SQLite.  It is not 'just' an ORM, and the ORM
>>> features may be optional, but they are still there.
>>> 
>>> If you are going to be pedantic, be accurate in your pedanticism.
>>> 
>>> 
>>> 
>>> 
>>> On Jun 22, 2013, at 10:37 AM, Kyle Sluder  wrote:
>>> 
 On Jun 22, 2013, at 12:55 AM, Rick Mann  wrote:
 
> 
> On Jun 22, 2013, at 00:50 , Keith J. Schultz 
>>> wrote:
> 
>> Core data helps in setting up the database, but deleting is another
>>> matter.
>> You should do that manually for consistency. Core Data has no
>>> knowledge of the
>> semantics of your database. so use prepareToDelete.
 
 I'm sorry, but what?
 
 1. Core Data is NOT a database. It is NOT an ORM. Core Data is a model
>>> object persistence and management framework. It just so happens that it can
>>> use a SQLit

Re: Why is it wrong to have relationships without an inverse in Core Data?

[Ian Joyner]

Thanks for the reference to Codd's early paper. I'm researching the relational 
model now since I'm giving a course in distributed systems soon. In fact, I'm 
reading Codd's 1990 book "The Relational Model for Database Management Version 
2". It is available as a pdf (although I have had the physical book for years. 
Also good are any C.J. Data writings.

"An Introduction to Database Systems" says "SQL is not perfect. SQL is very far 
from being the perfect relational language - it suffers from numerous sins of 
both omission and commission". In particular it allows duplicate rows which 
lead to anomalies. It is a shame the relational model has come to be judged by 
SQL (rather like one could judge OO by C++). While Codd was a researcher at 
IBM, SQL was done by a committee at IBM, and is fundamentally tasteless. SQL 
also breaks the terminology and confuses tables with relations.

Codd 1990 has chapter 23 "Serious Flaws in SQL".

Other models have come along, like Entity-Relationship (ER) and OODBs, 
supposedly addressing the 'weaknesses' of relational. But they fail for all 
their heavy marketing. OO really gets back to network and hierarchical data 
models. It is also record-at-a-time oriented which was the pre-relational 
approach. This makes applications and users far more dependent on the structure 
of the data. While the relational model well expresses semantics, building in 
too much semantics is a mistake and makes what you might think of tomorrow more 
difficult because you built today's assumptions into the model. The approach of 
Hammer and McLeod (which resulted in Unisys SIM, which seemed a good idea at 
the time) really failed.

ER distinguishes entities and relationships. However, relationships are just 
modelled by the single notion of relation. For example, 'marriage' is a 
relationship between two people, but this is just as well modelled by a 
relation as an arrow between two people in the people relation. You can also 
add extra information like date-of-marriage and date-of-end, reason-for-end, 
etc in a relation, which you can't to an arrow. ER is imprecise in these 
matters. Codd covers this well in chapter 30 and Date in chapter 14. ER 
diagrams can be useful, but we should not confuse diagrams with goodness, 
especially when they lack formality (like UML).

Another book available for free online is Hugh Darwen's:

http://bookboon.com/en/an-introduction-to-relational-database-theory-ebook

He has done a lot of writing with Date on marrying relational with OO the 
correct way (The Third Manifesto).

Perhaps all this answers the original "inverse relationship" question by saying 
relational doesn't have relationships other than by relating data values. That 
is there are no rat's nest pointers making the system brittle. I'd have to do 
some more thinking as to whether that is a weakness in CoreData or not, but it 
seems to be erring in the ER direction.

On 23 Jun 2013, at 11:04, Michael Crawford  wrote:

> Relational Databases and Databases in general are two different things.
> 
> E. F. Codd proposed Relational Databases in a 1970 Communications of
> the ACM paper that turned up instantly in a search.  Here's a PDF:
> 
>   http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
> 
> That paper itself says nothing at all about SQL, which is used to
> communicate between the database and either the end user, or software
> that acts on behalf of the end user.  Instead it discusses the logical
> structure of Relational Databases, with only databases that have that
> certain kind of structure being considered "Relational".
> 
> Part of that, for example, is the notion that there should be only one
> copy of any given item of data.  Say you stored Steve Wozniak's
> payroll information, and you put his salary in two different fields
> because it was convenient to do so, either because the client code was
> easier to write, or the data could be retrieved or stored more quickly
> that way.
> 
> Inevitably some innocuous error would result in the two copies
> becoming different from each other, and there would be Hell to pay.
> 
> There's a lot more to it than that.
> 
> Codd himself many years later - just a few years ago - spoke of his
> great disappointment with SQL, pointing out that SQL all by itself
> does not make any database at all Relational.  That's up to the
> database architect who designs its schema.  There are some things that
> the database vendors must implement, such as atomic and fault-tolerant
> storage, but any fool can create an Oracle or MySQL database that's
> not Relational by designing the tables, rows and columns in some
> manner of incorrect way.
> 
> There are many kinds of databases that are really great, but that
> don't even attempt to be Relational.
> 
> Mike
> 
> On Sat, Jun 22, 2013 at 3:03 PM, Charles Srstka
>  wrote:
>> On Jun 22, 2013, at 10:43 AM, Michael Crawford  wrote:
>> 
>> I don't use Core Data because it's not cross-platform.  In my honest
>> opinion

Re: Why is it wrong to have relationships without an inverse in Core Data?

[Ian Joyner]

The other reason I can think of for not classifying CoreData as a database is 
that CD is only meant for one application (at a time anyway), whereas specific 
databases (as in DB management systems DBMS) are meant to be shared on a 
massive scale.

Another interesting point from Codd is that he very much envisaged databases to 
be used by end users and not (just) by programmers. This was before Xerox PARC 
and Apple, and this is where SQL is a 'psychological' failure.

On 24 Jun 2013, at 11:23, Ian Joyner  wrote:

> On 23 Jun 2013, at 13:32, "Reaves, Timothy"  
> wrote:
> 
>> What the docs state that is meaningless (although inaccurate); the
>> Objectice-C manual could very easily state that Objective-C is not a
>> programing language; it is.  CoreData is a database.
> 
> OK, what the Apple doc 
> http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/CoreData/Articles/cdTechnologyOverview.html%23//apple_ref/doc/uid/TP40009296-SW1
>  says:
> 
> "Core Data is not a relational database or a relational database management 
> system (RDBMS).
> 
> "Core Data provides an infrastructure for change management and for saving 
> objects to and retrieving them from storage. It can use SQLite as one of its 
> persistent store types. It is not, though, in and of itself a database"
> 
> I agree with you in the general sense, but I think the docs are speaking in 
> the more specific sense. CoreData is really the middleman which can interface 
> to a number of data stores. To think of a database as a data store is also 
> misleading because the relational model is very high-level and very abstract 
> and about as far away from data store as you could get.
> 
> CoreData is more a modelling system (I could say data model... but it's not 
> that either). Thus programmers should be abstracted away from the physical 
> storage medium (which I think is a point you are making).
> 
> However, CD does rather look like the entity-relationship model, which is 
> fundamentally broken by distinguishing between entities and relationships and 
> lacks precision and formality (correctness and flexibility) which the 
> relational model has.
> 
> So in one sense you are right it is a database, but I'd say more a definer of 
> data models and these happen to get stored somewhere in a database. But CD is 
> not that database itself - it is the glue between the DB (or in-memory store) 
> and an application program.
> 
>> A database need never
>> write anything to a file.  There are - in fact - several examples, of all
>> manor, of in-memeory data bases that never bother to persist to a file.  As
>> the documentation points out, there are five(?)(XML, plist, SQLite, iCould,
>> in-memory) supported backing stores.  Four will cause a file to be created,
>> and one will not.
>> 
>> Yes, it's fully possible for CoreData to be broken into two components; one
>> that manages object graphs, and one that manages persisting them.  But
>> until that time, CoreData is a framework/library/module with the intention
>> of causing data to be stored, even if only in memory. That, by definition,
>> makes it a database, and when at least one particular backing stores is
>> used, it also makes it an ORM.  That it can do other things is irrelevant.
>> 
>> Now, enough with the philosophy!  :-D
>> 
>> 
>> 
>> 
>> 
>> On Sat, Jun 22, 2013 at 4:19 PM, Luther Baker  wrote:
>> 
>>> ... yes, and if you are going to be pedantic, please be somehow consistent
>>> with the docs:
>>> 
>>>> Core Data provides an infrastructure for change management and for
>>> saving objects to and retrieving them from storage. It can use SQLite as
>>> one of its persistent store types. *It is not, though, in and of itself a
>>> database.* (To emphasize this point: you could for example use just an
>>> in-memory store in your application. You could use Core Data for change
>>> tracking and management, but never actually save any data in a file.)
>>> 
>>> 
>>> http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/CoreData/Articles/cdTechnologyOverview.html#//apple_ref/doc/uid/TP40009296-SW1
>>> 
>>> 
>>> 
>>> 
>>> On Sat, Jun 22, 2013 at 1:26 PM, Timothy Reaves <
>>> trea...@silverfieldstech.com> wrote:
>>> 
>>>> Yes, CoreData is a database, and it does do ORM.  It's not just an ORM,
>>>> and it's not an RDBMS.
>>>> 
>>>> If it wasn't a database, it couldn't store data; that is the definition
>>>

Re: Why is it wrong to have relationships without an inverse

[Ian Joyner]

On 24 Jun 2013, at 02:11, Gordon Apple  wrote:

> You mentioned MacApp.  I was heavily involved in that for awhile and even
> got into the credits.  I don¹t know if you remember Bob Krause.  When I was
> running the developer sig at LA Mac Group, I had him down for a presentation
> on his object database backend, NeoAccess.  He had a version for MacApp, but
> I believe he also had one for Next Step.  

MacApp - I used to teach it as well. It was good in Object Pascal, but that got 
me into Eiffel to address the weaknesses of Object Pascal and the type system. 
But then Apple completely wrecked it by redoing it in C++. I'm still waiting 
for Eiffel to take off - it's not impossible - my wait for Apple (not Gordon 
:-)) finally paid off, but I seem to be old enough to be a teacher these 
days... oh well.

> I tried to get Apple, Inc. to look
> into it, but I guess they decided to go with their Enterprise Objects to do
> CoreData instead.  I wish they would take another look and consider doing a
> true object database engine using more of a CORBA-type interface, which, I
> believe, was attempted by Taligent, before Jobs killed it.

Enterprise Objects still is the best ORM around. The others mostly only do 
either new models or interfaces to legacy models, but not both. WebObjects is 
still worth a look at, although it was backed into the Java corner.

I can't comment on what you mean by 'true object' database engine, but it is my 
observation that most OODBs are based on extremely dubious foundations. Any DB 
really should be based on the relational model (Hmmm IBM got something right 
along with Fred Brooks), which can be extended with certain OO ideas like 
inheritance (EO does this rather well). In retrospect, I think Unisys made a 
huge mistake by not going more strongly with the relational model, although its 
DMSII could be used as a relational engine (and I did the Transparent Gateway 
interface to it), it was still rather record-at-a-time. Hammer and McLeod did a 
version of their Semantic Data Model (SDM) at Burroughs which was adapted to 
SIM (Semantic Information Manager), which also had inheritance. It was quite 
nice but didn't really get traction. Doug Tolbert, Randy Guck and others had a 
paper in Cardenas and McLeod 'Research Foundations in Object-Oriented and 
Semantic Database Systems'"

http://www.informatik.uni-trier.de/~ley/db/books/collections/cardenas90.html#JagannathanGFTT90

this is not a link to the paper - I can't find one, but here is another paper:

ftp://ftp.cs.utexas.edu/pub/techreports/tr03-43.pdf

I read some of the papers out of that book a few years ago, trying to clarify 
my thoughts on DBs and came to the conclusion that putting semantics at that 
level is a bad idea and that the level of semantics in the relational model is 
correct (although the OO and ER crowd frequently states that the relational 
model does not include semantics). I think the correct place to put semantics 
is in the applications - it is too hard (read non-agile) to predict all the 
possible uses of a DB up front and include it in the DB.

As for CORBA-type interface - that was one of the worst interfaces ever - a 
complete committee designed C++ mess. CORBA really is dead - the answer is 
REST. Michi Henning's article in ACM Queue is interesting reading on CORBA's 
fate.

http://queue.acm.org/detail.cfm?id=1142044

> 
> On 6/22/13 2:00 PM,  Michael Crawford  wrote:
> 
>> I don't use Core Data because it's not cross-platform.  In my honest opinion
>> no one in their right mind would bet their livelihood on platform-specific...

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why is it wrong to have relationships without an inverse in Core Data?

[Ian Joyner]

So I think, if I understand what Graham is suggesting, that in a relational DB 
design you would model this with three relations 1) Parent 2) children (which 
could be the same as parent) 3) active_children. If a child is active you 
insert it in the active_children set (relation is a particular kind of set). 
When no longer active, delete it. That could be modelled in CD, but Rick could 
decide if that actually solves his requirement. In CD, you'd still need the 
relationships and inverse relationships via the intermediate relation, so I'm 
not sure if this does solve his problem. But I think it shows that the 
relationships of ER can all be modelled using entities and the lack of clarity 
of "what's an entity and what's a relationship" disappears.

On 25 Jun 2013, at 11:01, Graham Cox  wrote:

> 
> On 25/06/2013, at 12:49 AM, Flavio Donadio  wrote:
> 
>> Rick Mann, I don't understand why you need a separate relationship to 
>> retrieve the active Child objects. Please, consider doing this:
>> 
>> Parent
>> children to-many to Child
>> 
>> Child
>> parent   to-one to Parent
>> active  (boolean)
>> 
>> And then create an activeChildren: method in Parent with returns only the 
>> active children.
>> 
>> Sorry if this is not acceptable. I am just trying to help.
> 
> 
> In my experience, this is not a good design pattern.
> 
> It's common to want to maintain a subset of some collection (and it may be 
> that the subset can have at most a single member, as in Rick's case). Using a 
> boolean as a state variable in the objects to indicate membership of this set 
> is poor design because it a) requires a lot of management to turn off those 
> that become deselected, and b) requires much more time to iterate over the 
> collection to find the subset when needed, c) requires additional work if 
> there can be multiple, orthogonal sets of this nature.
> 
> Using the language of sets it becomes clear how to do this much more 
> efficiently: use a set! The NSSet class, and its cousin NSIndexSet, are ideal 
> for this purpose. If it's in the set it's a member, otherwise not. It's fast 
> and efficient, simple to extend without the member objects ever having to 
> care about it. Sometimes the member object will want to ask "am I a member of 
> such-and-such a set?", and this is where the child->parent relationship can 
> be used.
> 
> This is independent of Core Data, I'm not sure what features it has to 
> support this concept - maybe none, as typically this sort of subset 
> (selection) management is handled at the controller level.
> 
> I commend it to the house.
> 
> --Graham
> 
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Reverse Engineering KickStarter Project

[Ian Joyner]

On 23 Jun 2013, at 11:38, Michael Crawford  wrote:

>> To me, it's not that you'd have to write all the code from scratch that 
>> makes Core Data concerning, it's the fact that the format is undocumented.
> 
>> If Apple published a complete specification for the format, I'd be willing 
>> to use Core Data, but as it is, the prospect of having
>> one's own file format as a black box is a huge turn-off to me.
> 
> 
> Thanks for tip, I was unaware of that.
> 
> Sure I can see how it's nice to use the Core Data API, but one would
> have to be completely out of one's tree to save end-user documents in
> a completely undocumented format, even if it were cross-platform.

I don't think you would have to be completely out of your tree. The precedent 
is encapsulation - you should not care about internal layouts, only what the 
API exposes it. Seems that is exactly what CD does. And I think CD does give 
some extra discipline in modelling things correctly and making it easy to 
persist things, so I think it's doing a lot for you, notwithstanding my 
concerns that it might be more ER than relational. Most DBMSs also do not 
publish their internal file formats because these can change and if the 
abstraction is good - completely irrelevant. Thus application programmers 
should be encouraged to be loose coupled on the internals of a system, only 
using it in the published ways.

However, I can see your point that it is a concern that if Apple discontinues 
CD that suddenly we have a whole lot of unreadable data and really anything 
stored persistently should be cross-platform whether stored on disk, or 
transmitted across a network. But perhaps to do that, just a small utility 
program that uses to CD API to get the data will suffice.

But it is a little like the Carl Sagan records sent out on Voyager I (I think) 
for aliens to enjoy - now how are they going to do that without a record 
player? It will be like trying to decipher the Dravidian script of Mohinjo-Daro 
(we got lucky with Hieroglyphics with the Rosetta Stone). Vint Cerf recently 
stated that we might lose a lot of data because we lose the ability to 
interpret it (not such a new thought - one of the threads of Godel, escher, 
Bach).

> 
> I lost what would have otherwise been a really lucrative, really fun
> consulting gig in which I would have been able to use my Physics
> degree.  I'm afraid that I made it clear to the hiring manager that I
> considered him an idiot for even asking me whether I knew Core Data.
> I didn't come right out and say so, but I sure did make it clear that
> I considered him ill-advised.
> 
> Just now I'm about to register a KickStarter project that would
> compensate me for completely reverse-engineering the Core Data
> formats.
> 
> However I need to set a fixed price goal, as well as a finite delivery
> schedule.  One only gets money at all from kickstarter if both goals
> are met.  That kind of project estimation, in my own experience, is an
> as-yet unsolved problem, not just for me but for every software
> engineer.  If you claim you know how to estimate software development
> time and cost, I don't believe you.
> 
> Don't even _think_ about suggesting that such reverse-engineering is
> illegal.  Reverse-engineer is specifically protected under the law.
> 
> If you have some proprietary method you want legal protection for,
> that's what patents are for.
> 
> Trade secrets are used either when the invention is either not
> "novel", or not "unobvious" and so not legally patentable, or when one
> hopes to maintain the secret for longer than the patent's twenty-year
> term, such as the secret recipe for Coca-Cola.  There are only a very
> few, very trusted people who know what all the ingredients are.  Had
> they patented it, the recipe would have been placed into the public
> domain a hundred years ago.
> 
> I know this very well.  I've reverse-engineed a whole bunch of
> different kinds of things.
> 
> That resulted in a Senior Engineer position at Apple itself in the
> mid-90s, where in my role as a Debug Meister for the Traditional OS
> Integration team, I reverse-engineered a great many third-party
> applications that were found by QA to stimulate crashes in new builds
> of the Mac OS System.  I worked on 7.5.2 and 7.5.3.
> 
> For example, I once supplied Microsoft with the exact byte offset in
> the Word 6 binary, at which they started a one-shot timer, then after
> it fired, reset it, so it would tick continuously.  Unfortunately, the
> Classic Mac OS didn't have any really clear concept of a process -
> some other Apple engineer once described the System as just "a bunch
> of subroutines", so under a very heavy paging load, that timer would
> fire well after Word's executable code had been overwritten with some
> other data.
> 
> 
> My very first consulting gig when I hung out my shingle in April 1998,
> was to reverse engineer the Movie Magic Scheduling database format, so
> that Graphical Planet's handheld devices c

Re: Why is it wrong to have relationships without an inverse in Core Data?

[Ian Joyner]

Was there ever a satisfactory answer to this? I'm not sure what the CD 
modelling answer is, but this seems to be related to relational modelling 
referential integrity or in plainer language - no dangling pointers - in db 
language a foreign key must have a primary key in another relation.

For example if there is no inverse in the active child and the active child is 
deleted, the active_child foreign key will be left as such a dangling foreign 
key. (That is why your second solution clobbered original key.)  It needs to be 
set to nil (meaning value either not known or not applicable). This leads to 
Codd's 3- and 4-value logic, which is contentious in itself (Date does not like 
it and forbids null values). But you can answer that question 'Does the parent 
have to have an active child or not?'. That is an application-level integrity 
constraint.

The structure is not the only thing that needs to be considered, but what 
happens when changes are applied to that structure as well. (Reminds me of 
Steve Jobs quote of Design is not just how it looks, but how it works as well.)

On 22 Jun 2013, at 06:55, Rick Mann  wrote:

> I find myself frequently wanting to do something like this:
> 
> Parent
>  children to-many to Child
>  activeChild  to-one to Child
> 
> Child
>  parent   to-one to Parent
> 
> But Core Data complains that activeChild is misconfigured because it doesn't 
> have an inverse. But I have no need for an inverse, why does Core Data?
> 
> Thanks,
> 
> 
> -- 
> Rick
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Have questions...

[Ian Joyner]

On 13/06/2008, at 2:09 PM, Rick Langschultz wrote:

Am I aloud to ask where I can submit my iPhone programming questions  
to?


Yes, much to loud!
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Dot Syntax docs missing?

[Ian Joyner]

On 19/07/2008, at 11:36 PM, Michael Ash wrote:

On Sat, Jul 19, 2008 at 1:14 AM, Rick Mann <[EMAIL PROTECTED]>  
wrote:


On Jul 18, 2008, at 21:51:57, Jerry Krinock wrote:

setEp1: should work.  The colon is significant and is a part of  
the method

name.


In fact, I do have the colon in the actual definition. Definitely  
something

else is going on, I think.

I would advise you to embrace and learn both the dot syntax and  
square

brackets.


Well, I'm forced to use the square brackets for method calls  
(excuse me,
"message sends"), and I love square brackets as array index  
operators. I

don't think I'll ever embrace them for method dispatch.


The universe of programming languages extends far beyond this little
island of ALGOL-lookalikes. Objective-C messaging syntax is utterly
mundane compared to many common, useful syntaxes used in practical
(but different) languages every day. IMO you do yourself a disservice
if you don't branch out and try some different things once in a while,
and remember that they're just programming languages, and syntax is
just syntax, nothing really all that important.


Except that syntax is the medium to convey meaning, thus to make it  
easier for others to understand what a program is about. If it were  
not so, we may as well have stuck to programming machine language in  
1s and 0s. Thus syntax is important... or at least the manifestation  
of that which is important.


I like a Steve Jobs quote from 1996: “Design is a funny word. Some  
people think design means how it looks. But of course, if you dig  
deeper, it’s really how it works.” Clean syntax reflects clean  
functionality. The bracket syntax of Objective-C reflects the fact  
that it was a preprocessor rather than compiler. C's syntax reflects  
the fact that much unnecessary implementation detail could not be  
handled by a 1960s PDP 8 compiler. Of course, C.A.R. Hoare did quip  
that ALGOL was an improvement not only on its predecessors, but on  
most of its successors as well.


Ian___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa Dev Style: Using Class versus Object Methods

[Ian Joyner]

It's not style, but a technical consideration. Class-level things are  
shared and common between all object instances. They are thus like  
globals, but obviously better organized. Class-level methods cannot  
access things at the object level. Objects have their own different  
values of attributes.


Putting things on the stack is only an optimization which some OO  
languages let you do, if you know certain conditions will be met.


Ian

On 08/08/2008, at 3:08 AM, Lee, Frederick wrote:


Greetings:

   I just came across a NSObject subclass written by someone, that
contains a couple of date/Time-processing methods (stringToDate,
visa-versa).

The methods were all class-level methods (+) vs (-); and hence, didn't
require the familiar alloc & init instantiation methods.



I've been writing NSObjects via instantiation (requiring alloc & init)
that I use to model business logic (packing XML data vectors, etc.)  
and

hold a lot of common methods to use.



I can see a project using class methods instead of instantiated  
methods;

and hence, avoid the alloc/init memory hassles.



My question (which is ELEMENTARY), is

1)  why use instantiated objects versus classes (via class  
methods)?


2)  Are classes stored in the stack & instatiated objects on the
heap?





Ric.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/i.joyner%40acm.org

This email sent to [EMAIL PROTECTED]

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: ObjC 2.0, properties, KVC, special _ hacks etc.

[Ian Joyner]

On 22/08/2008, at 12:59 PM, Thomas Engelmeier wrote:


Am 22.08.2008 um 00:59 schrieb Dave MacLachlan:

Also, are the _ in front of member variables for Apple only (so we  
don't stomp on each other with member var names) or are they using  
them for the readability reason mentioned above? There is  
documentation where they have claimed _ at the beginning of method  
names as being Apple only, but nothing about method vars, and the  
KVC compliance docs seem to imply that it is fine to do.


Officially it is Apple only, but everybody and his dog uses it - in  
consistency to quite some Apple-provided samples.
Also, in C++ the _ variable prefix is reserved for stdlib- 
implementation.
The reasoning why many people do not consider it as problematic if  
there is a collision with an Apple defined _ prefixed ivar is you  
will see an compiler error once there is a collision.


Which pretty much means the preceding _ is just noise and gibberish  
and therefore plain bad style – something to avoid, it's not clever  
programming. Good style is to choose plain-language identifiers. The  
use of _ is to put white space between words in long identifiers, in  
contrast to poorly readable camelCase (maybe that should be hunchback  
case). (And note the spaces are outside the parentheses, not inside.)  
Why is it programmers generally choose the less-good way to do things,  
like programming Windows and C++!!


For methods OTOH, you don't get an warning but potential runtime  
crashes and undefined behavior.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Cocoa and the need for a dynamic language

[Ian Joyner]

On 18/01/2009, at 1:51 PM, Erik Buck wrote:


Both Objective-C message sending and C++ virtual function calls  
commonly prevent in-lining because the _compiler_ can not determine  
which code will actually be called.  If you use Objective-C message  
sending or C++ virtual member functions, you forego most low level  
optimizations at the call sites.


Nicely stated. Presumably, one is using a dynamic method because you  
are having to defer to runtime exactly what code will be executed. If  
you did not have dynamic method dispatch, you would have to explicitly  
write the decision mechanism in the code yourself (conditionals or  
case statements). That is, the complexity does not go away – it may be  
that the complexity of the method dispatch has to be explicitly coded.  
A recent article on computer architecture states this "complexity  
preservation principle" rather clearly:


http://www.embedded.com/columns/technicalinsights/29111964?_requestid=1581

Now in Objective-C, the compiler (or linker) can't do static analysis  
to remove unnecessary method dispatches because your system is  
effectively open (dynamic) to have various add ins (categories, etc)  
that can happen at runtime. If a system is closed (as with Eiffel), a  
compiler can be much more ruthless in its optimization attempts, but  
of course you lose the ability to dynamically add functionality. With C 
++, the complexity is to a very large extent left inelegantly up to  
the coder. Many programmers seem to feel safer that way.


Ian___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSNull and @""

[Ian Joyner]

On 11/10/2008, at 9:33 AM, Seth Willits wrote:


On Oct 10, 2008, at 3:20 PM, DKJ wrote:

I've made an NSDictionary where the values are strings. Is there a  
difference between setting a value as [NSNull null] and setting it  
as @""? (I've been using the former.)


Is there a difference? Definitely. One is an instance of NSString,  
the other is an instance of NSNull. NSNull is not special. It's an  
object just like any other.


I'm just trying to work out what NSNull really is in the Cocoa  
context. Is it an object in Cocoa? I think (from other environments)  
that it is a type signifying "no object". Since NSNull may be a  
"valid" value of any other type, is it counted as a subtype of every  
other type (hence the ultimate subclass)? I think a good and simple  
(one that doesn't make my brain hurt) definition of NSNull is  
important in order to ensure software correctness.


"Passing paths that climb half way into the void"

Whether you want to use an empty string or an NSNull is up to you.  
If an empty string is a legal value, then you could use NSNull to  
represent there being no value given. (Or just simply don't have  
anything in the dictionary.)



--
Seth Willits


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSNull and @""

[Ian Joyner]

On 11/10/2008, at 11:58 AM, Seth Willits wrote:


On Oct 10, 2008, at 5:40 PM, Ian Joyner wrote:

I'm just trying to work out what NSNull really is in the Cocoa  
context. Is it an object in Cocoa?



As I said, yes. It's truly an object. (A singleton, as well.)



Since NSNull may be a "valid" value of any other type, is it  
counted as a subtype of every other type (hence the ultimate  
subclass)? I think a good and simple (one that doesn't make my  
brain hurt) definition of NSNull is important in order to ensure  
software correctness.


Woah. Talk about brain hurt. You're thinking about this far too much.


I don't think you can think about anything too much. If one doesn't  
have a clear understanding of the semantics of programming constructs  
then resultant software full of bugs (I'm sure Confuscious said  
something like this several thousand years ago). Perhaps that's why we  
have become so test dependent – don't think, just test. Well, I'll  
refrain from going further into a philosophical debate at this point.


There's no inheritance, there's no nothing. It's an object. It's  
absolutely in no way different than you creating your own IJNull  
class, and sticking an instance of it anywhere. It doesn't behave  
any differently.


As for use, the documentation says it pretty clearly:

"The NSNull class defines a singleton object used to represent null  
values in collection objects (which don’t allow nil values)."



You can't stick nil into dictionaries and arrays. So either you  
stick an empty string, an NSNumber with 0, etc if those are OK, or  
you can use NSNull.


So it's really a workaround for this situation. I think therefore  
there are several constructs to represent the same concept of "lack of  
presence" – nil, Nil, Null, and NSNull.


Sorry, but NULL values need very careful reasoning and handling. (See  
C.J. Date "Database Systems" 5.6 Nulls (A Digression).) Thanks for  
your insights.


Ian___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSNull and @""

[Ian Joyner]

On 11/10/2008, at 12:31 PM, Kyle Sluder wrote:


On Fri, Oct 10, 2008 at 8:40 PM, Ian Joyner <[EMAIL PROTECTED]> wrote:
I'm just trying to work out what NSNull really is in the Cocoa  
context. Is
it an object in Cocoa? I think (from other environments) that it is  
a type
signifying "no object". Since NSNull may be a "valid" value of any  
other
type, is it counted as a subtype of every other type (hence the  
ultimate
subclass)? I think a good and simple (one that doesn't make my  
brain hurt)
definition of NSNull is important in order to ensure software  
correctness.


The type system can, and often must, be willingly ignored, so you
can't rely on it to demonstrate anything about your program's
correctness.


So we must be dependent on testing, which I find compelling like agile  
programming, but ultimately very hit and miss.



If it's a strong type system you seek, I suggest you look elsewhere.


Insofar as strong typing helps software correctness, but as such, not  
necessarily strong typing. I appreciate the flexibility of dynamic  
languages, but one can have this also in strong typing.


Like, somewhere other than desktop Macintosh software development,


Why would I want to do that?


for
which all the popular languages have incredibly weak type systems.


Popular does not necessarily imply good, only democratic.

Ian
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: NSNull and @""

[Ian Joyner]

On 11/10/2008, at 2:18 PM, Kyle Sluder wrote:


On Fri, Oct 10, 2008 at 10:33 PM, Ian Joyner <[EMAIL PROTECTED]> wrote:
So we must be dependent on testing, which I find compelling like  
agile

programming, but ultimately very hit and miss.


Luckily the Developer Tools come with the OCUnit unit testing  
framework.



If it's a strong type system you seek, I suggest you look elsewhere.


Insofar as strong typing helps software correctness, but as such, not
necessarily strong typing. I appreciate the flexibility of dynamic
languages, but one can have this also in strong typing.


Perhaps I should use the terms more correctly.  ObjC is late-bound,
and *very* frequently Cooca will go and change the class identity of
the objects you're working with.  A great example is KVO: if you
register as an observer of a MyObject, then KVO will actually
completely replace your MyObject instance with an instance of some
dynamically-generated _KVONotifyingMyObject class, and your code will
be none the wiser.

Essentially, you are giving up a lot of static analysis opportunities
in order to avoid the behavioral restrictions they impose.  In this
case, you have mentioned NSNull in a context that is more familiar to
languages with well-developed type systems such as Haskell.


Hmm, I have both the Smalltalk and Haskell books sitting on my desk  
for restudy. I think you have given me the impetus to study them  
together from this angle. Thanks.


Objective-C foregoes this formal type system so that things like KVO
can function.  It's a tradeoff, to be sure.


I'll have to think more about this. I'm not sure that KVO can't be  
done in a type-safe manner.



Like, somewhere other than desktop Macintosh software development,


Why would I want to do that?


I'm not advocating that you do!  It was a rhetorical device.


Glad to hear that. I won't be abandoning Mac after 20 years anytime  
soon for that hopeless case Windows.




for
which all the popular languages have incredibly weak type systems.


Popular does not necessarily imply good, only democratic.


I'm just noting that no reasonably well-supported development
environment on the Mac will provide you features such as a type system
in which a null type exists that is a subtype of all other types.
Pattern-matching languages, like Scala for example, are great for this
sort of thing, but you won't find one that is suitable for developing
desktop Mac applications.  Perhaps that will change in the future.


I don't think the two are mutually exclusive. In a type-safe  
environment, type errors are caught (tested) by the compiler (so you  
don't need to develop tests for these cases). There are known  
situations where you don't want this, but to defer the exception to  
run time. A language can easily be defined to allow for this. It came  
up a while ago and I wrote an article on it:


http://web.me.com/ianjoyner/Ian_Joyner/Typing.html

I also wouldn't discount it happening in the future, after all Obj-C  
2.0 gave us garbage collection.


Ian
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: MVC

[Ian Joyner]

On 24/10/2008, at 1:30 PM, Erik Buck wrote:


Blatant plug:

See also http://safari.informit.com/9780321591210

Part I: One Pattern to Rule Them All


Is there a section "Return of the Controller"?

Looking forward to reading your book.


Model View Controller

Examples of MVC in Apple Frameworks

Chapter 1. Model View Controller

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: MVC

[Ian Joyner]

On 24/10/2008, at 4:42 PM, Carlos Weber wrote:

No one can have a complete understanding of MVC without hearing  
James Dempsey (an Apple engineer) explicate it:


http://www.youtube.com/watch?v=YYvOGPMLVDo


Excellent. And I thought MVC was Mountain View, California!

Actually, I first came across it while doing MacApp about 20 years ago  
and reading Brad Cox's book on some obscure language called Objective- 
C... whatever happened to that?


James's observation about a string maybe containing a phone number or  
the works of Aristotle not being of concern to the view, but being in  
the Model's domain does raise the difficulty in it – where does  
semantics of information come in and specifically validation. With web- 
based applications, we are putting more into JavaScript, where the  
view may check that something looks like a phone number (rather than  
the works of Aristotle), thus giving a user a better interface (error  
message, rather than "Windows has found an error, error number 60532,  
click here to find out more information about what this is about"). It  
can also provide a faster feedback loop to the user than sending a  
message to a server to get "Invalid data" back.


As for the original question. there aren't hard and fast rules about  
MVC, but it certainly helps design any app by using its guidelines.  
Within Cocoa, however, there is a lot of support with Core Data  
helping with the model and bindings helping with doing a lot of that  
boring controller stuff, and obviously nib files (xib, and Interface  
Builder) isolate the view for you.


Ian___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: New to Cocoa and Objective C, and I need some basic pointers

[Ian Joyner]

On 06/12/2008, at 8:26 AM, [EMAIL PROTECTED] wrote:

Basic (Beginner's All-Purpose Symbolic Code) was used on Apple IIs  
(although we wrote our own ALGOL-like language at the first Apple- 
based company I worked at). It is generally MIA (like body of  
message!) on Mac, except for third parties like RealBASIC. Otherwise,  
Microsoft still seem to persist, but I would not point you in that  
direction :-)


Ian
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Problem posting to this list?

[Ian Joyner]

I mysteriously got messages about too many bounces a few weeks ago, both for 
Cocoa and WebObjects. Replying to the message or clicking the confirmation page 
did not work. I reenabled manually at the mailing lists site. The links took me 
to legitimate Apple pages, not some scam site, but it did seem suspicious. So 
if anyone knows of any security problems, please post here. Message as follows:

Your membership in the mailing list Cocoa-dev has been disabled due to
excessive bounces The last bounce received from you was dated
25-Apr-2014.  You will not get any more messages from this list until
you re-enable your membership.  You will receive 2 more reminders like
this before your membership in the list is deleted.

To re-enable your membership, you can simply respond to this message
(leaving the Subject: line intact), or visit the confirmation page at

   https://lists.apple.com/mailman/confirm/cocoa-dev/


You can also visit your membership page at

   https://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com


On your membership page, you can change various delivery options such
as your email address and whether you get digests or not.  As a
reminder, your membership password is


If you have any questions or problems, you can contact the list owner
at

   cocoa-dev-ow...@lists.apple.com

On 12 May 2014, at 10:47, ChanMaxthon  wrote:

> I have caught two too-much-bounce alerts and it started to smell like 
> deliberate attackers.
> 
> Sent from my iPhone
> 
>> On May 12, 2014, at 8:41 AM, Quincey Morris 
>>  wrote:
>> 
>>> On May 11, 2014, at 17:30 , William Squires  wrote:
>>> 
>>> I'm getting a mysterious message
>> 
>> Yes, me too. I think the explanation is that someone subscribed to the list 
>> has had their email account hacked (or possibly just misconfigured), and 
>> there is some kind of bounce from their message delivery. Maybe the bounce 
>> message is actually malware. I’ve also been seeing other spam making it 
>> through spam filtering recently, and I suspect it’s related.
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com
>> 
>> This email sent to xcvi...@me.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com
> 
> This email sent to ianjoy...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com