tag:blogger.com,1999:blog-1688176320920284646.post7196060915234452229..comments2023-12-20T10:24:23.540+00:00Comments on A day in the life of...: Cocoa, falling at the first hurdle?Unknownnoreply@blogger.comBlogger6125tag:blogger.com,1999:blog-1688176320920284646.post-3320721265294680032007-09-14T08:00:00.000+01:002007-09-14T08:00:00.000+01:00Private in Delphi works more like "internal" where...Private in Delphi works more like "internal" where classes in the same unit can access it.<BR/><BR/>Actually I wrote most of my code in C# these days, and private works fine there. Sure you can get a method using Reflection, but that could hardly be done accidentally.<BR/><BR/>My gripe with objective-c is that it would appear to be very easy to accidentally execute "private" methods because there is no way of knowing it is private. With proper encapsulation I can make my class appear to be much more simple to the consumer by only exposing one or two methods and then having the other 200 methods private.Peter Leslie Morrishttps://www.blogger.com/profile/09377536995235480828noreply@blogger.comtag:blogger.com,1999:blog-1688176320920284646.post-3138720825753073922007-09-13T21:56:00.000+01:002007-09-13T21:56:00.000+01:00Sorry, I meant to say, that "within a delphi unit,...Sorry, I meant to say, that "within a delphi unit, you can access private symbols between classes". That's not private, and thus Delphi is broken, but those of us who are used to it, are used to it. That's what I was trying to say. But my fingers couldn't keep up with my brain. I'm an idiot too. So there.<BR/><BR/>WWarrenhttps://www.blogger.com/profile/04053407632823479165noreply@blogger.comtag:blogger.com,1999:blog-1688176320920284646.post-53364329371863269612007-09-13T21:55:00.000+01:002007-09-13T21:55:00.000+01:00Visibility specifications are syntactic sugar, and...Visibility specifications are syntactic sugar, and can be overcome, in Delphi.<BR/><BR/>You are using a broken system already. Right? Delphi.<BR/><BR/>Visibility specifications are moot. <BR/><BR/>What would you say to somebody who said, "Fine I won't use Delphi", and then proceeded to use Visual Basic instead. <BR/><BR/>You'd say, "You're an idiot", and you'd be right.<BR/><BR/>Right now, You're being an idiot.<BR/><BR/>Give Objective-C a chance. I am a delphi bigot and I know how you feel. But it's stupid to drop the whole thing on that basis.<BR/><BR/>WarrenWarrenhttps://www.blogger.com/profile/04053407632823479165noreply@blogger.comtag:blogger.com,1999:blog-1688176320920284646.post-88581243705725160592007-06-18T18:47:00.000+01:002007-06-18T18:47:00.000+01:00I used Obj C for a brief stint years ago; that sai...I used Obj C for a brief stint years ago; that said, I've forgotten a lot of its details.<BR/><BR/>However, one thing I remember throughout using it: it is very much different from "normal" C-based OO languages and its solutions to common goals or problems are different. Specifically: protocols, categories, delegates, clusters etc.<BR/><BR/>I'd suggest reading the rest of the book before you pass judgement. :-) There may be different ways to accomplish what you're looking for.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1688176320920284646.post-83714799975498997962007-06-18T08:40:00.000+01:002007-06-18T08:40:00.000+01:00I disagree.If I order a car from a manufacturer th...I disagree.<BR/><BR/>If I order a car from a manufacturer their interface to me asks a few things such as "What size engine?" etc. I do not need to know about the thousands of internal processes etc. (They could be made private.)<BR/><BR/>Within that company they most likely have variations of those processes (make those protected.)<BR/><BR/>The problem is that there is no such thing as protected in objective-C. So those would have to be made public. Don't you think that over complicates the interface that the consumer of my class has to work with? It also exposes methods that should be called only in specific circumstances.<BR/><BR/>What you seem to be describing is abuse of encapsulation which then requires hacking. You can abuse any technology. Preventing sensible users from doing something just because someone else abuses it is not a good thing.Peter Leslie Morrishttps://www.blogger.com/profile/09377536995235480828noreply@blogger.comtag:blogger.com,1999:blog-1688176320920284646.post-6497808980658553112007-06-18T04:40:00.000+01:002007-06-18T04:40:00.000+01:00(disclaimer: I'm not an Obj C'er or even die hard ...(disclaimer: I'm not an Obj C'er or even die hard Mac)<BR/><BR/>To be honest I always have been a bit surprised by the fanatism of people in relation to information hiding.<BR/><BR/>People seem to consider it a purpose in itself, instead of a means to reach a goal.<BR/><BR/>Basically there are two possible roles in information hiding:<BR/><BR/>The role of the normal programmer: avoid stupid mistakes. This role needs a basic private/public, the rest is IMHO redundant and way overrated.<BR/><BR/>Some people also see a separate role for the component builder, usually with as much control as possible, to make sure the component is used in the way they envision.<BR/><BR/>That is IMHO also the problem with that view, nobody can imagine all possible uses and ways to extend a component, in all situations.<BR/><BR/>THerefore you see codebase after codebase that uses all kinds of dirty hacks to get at private fields, change visibility etc, leading to more obfuscation then simply doing away with it.<BR/><BR/>So in short, maybe it is a good thing.Anonymousnoreply@blogger.com