Asset, asset, *assets..(name change recommended)


#1

Like other members, this Chapter made me realize a need to change my thinking in a more Object-oriented way. I found taking time to draw out object diagrams to be very helpful. Keeping track of relationships between objects, methods, pointers, and files to be too much to keep track of in your head, at least as a beginner. I reread the last 3 chapters because i felt like i was missing something, then i started a new project from scratch for Employees and Assets. I finally feel like I’am ready to move on now. I find it hard to read code and visualize what’s going on when names of objects are soo similar. Changing the name of the array assets to something more objective sounding immediately made the code more readable and less confusing. :wink:

[code]@interface Employee : Person
{
int employeeId;
NSMutableArray *assContainer;

}[/code]

[code]-(void)addAssetObject:(Asset *)a
{
//is assContainer nil?
if (!assContainer) {assContainer = [[NSMutableArray alloc] init];}
[assContainer addObject:a];

}

-(unsigned int)valueOfAssets
{
//sum up the resale value of the assets
unsigned int sum = 0;
for (Asset *a in assContainer){
sum += [a resaleValue];
}
return sum;
}[/code]


#2

assContainer :mrgreen: less confusing? :wink:

P.S. Just a joke, don’t get me wrong :slight_smile:


#3

Good laugh, but the truth is more serious. This book, along with every book in this area that I’ve read, and every forum post in any forum that I’ve read, either totally obfuscates the underlying syntax or swans off into foo-land. Which to a beginner is even worse.

Here’s what’s wrong. I’ll give a few examples. The first is from very early on in this book:

{ Person person;
The problem with this is in using the apparently same name for two completely different things. Yes, Yes, I know, one starts with a capital P and the syntax makes it obvious that Person and person are different things - but this is just page 66 in an introductory book, and nowhere (that I could find up to that point - I could be wrong) did the author suggest that using a capital P will help differentiate between a class and an instance. At this stage in a book, we need our hands held a lot.

So this following code example is poor from a teaching point of view, since it is very confusing for a newbie. Here, in page 102, we’re creating an instance of our brand new class Person:

Why on Earth could he not have said:

and made it totally clear what was happening? This obfuscation is repeated throughout the book.

I am also working my way through Mark et al’s book on iPhone Development, and it’s even worse. It’s full of stuff like this:

and to be honest he’s not trying to teach Objective-C, but rather than just copying this syntax from Apple’s docs, he could have made it easier for tyros like me by using something like:

to at least show where the reserved variables are required (and some highlighting there would help too, like italics) and where your own stuff can go in - and even though I had already got as far as page 115 in Hillegass before getting to this, I had to actually try out all the combinations in Xcode to see where it fell over, before I knew that the first use of pickerView was essential and had to be exactly that, whereas the second could be anything I liked, provided I used that in the subsequent code. Same with component.

So avoiding keywords in the code examples, apart from where these keywords are required by the syntax, and then highlighting these as keywords, would really, really have made my life a lot easier and my understanding would have come much quicker.

As for Foo and Bar, I don’t know why people use that. It obviously means something to experts, but a newb seeing that stuff is left wondering what these things are. Sometimes they are classes, sometimes they are instance variables, and always that are just a pain in the… foo.


#4

Keep an open and focused mind when learning new things because the world is not perfect and you are in that world.

Try to focus on the material being presented, not on the presentation style; it may not be perfect but that’s all you have.

Use the forums to ask intelligent questions if you don’t understand something, or to share information that you think others may benefit from.

Get used to the way of doing things in the BNR books and in the Developer Documentation, because people who have created those resources have more experience than you and they don’t take things lightly.

If you maintain an open and focused mind, you will find your learning experience more pleasant and also more rewarding.


#5

[quote=“ibex10”]Get used to the way of doing things in the BNR books and in the Developer Documentation, because people who have created those resources have more experience than you and they don’t take things lightly.

If you maintain an open and focused mind, you will find your learning experience more pleasant and also more rewarding.[/quote]
Sorry, I don’t accept that I don’t have an open and focussed mind, and I also don’t believe that you see what I mean. Can I give another example?

In Mark’s book, he introduces a new concept, a reusable cell identifier in a table view in iOS. This is our first stab at understanding table views. Here is some code that he asks us to use:

and I think that his choices of stuff in that line is really unhelpful. This is not about style, but about trying to help learners understand stuff. I have no idea if the system requires the identifier string to be the same as the identifier label or not, or if the capitalisation is meant to indicate something important about the code or not. So I’m left feeling uncomfortable in the use of that code. I’m not just going to blithely use code that I’m not comfortable with, because that attitude will surely return to bite me.

However, I changed the code to this:

where “Foo” is as close as I can get to swearing in this forum. This code worked, of course, and has the advantage of not making me wonder what might be going on behind the scenes. Again, I just don’t understand why Mark didn’t use something like that.

I truly think that this is an issue, but you don’t have to agree with me. You also don’t have to tell me that I’m not focussed.


#6

I am curious to find out why such a simple declaration such as the following should be confusing.

static NSString *Foo = @"Foo";

I suspect the confusion is primarily being caused by the lack of a firm understanding of the basic concepts: the name of a variable (Foo) can not have any bearing on the content it designates (@“Foo”) and vice versa.

As for “if the system requires the identifier string to be the same as the identifier label or not,” the answer is no because the system (by which if you mean the UITableView) does not know anything about the names of the identifiers used in the program. To find out if it cares about the content itself, you need to read the Class Reference.

Also the language (or its compiler) does not care about the capitalisation of the identifiers you create at all, as long as you don’t use the same identifier in a given scope to designate more than one object.

Capitalisation of identifiers is only culturally significant within a programming community or within a framework. For example, in Apple’s class frameworks the class names start with a capital letter. In Microsoft communities they (the class names) probably start with a capital C. Again the language or its compiler does not care (at least the ones that I know of.)


#7

[quote=“ibex10”]
I am curious to find out why such a simple declaration such as the following should be confusing.

static NSString *Foo = @"Foo";

I suspect the confusion is primarily being caused by the lack of a firm understanding of the basic concepts[/quote]
Absolutely. That is exactly why I’m reading the book. If I had a firm understanding of this, I would not be posting here. Well, of course, I now do understand the differences between these two Foos, but not because of the book. As I have said twice before, it is quite unnecesary to use *Foo and “Foo” and for a beginner it’s confusing and obfuscates the concepts. You have forgotten how much baggage a beginner brings to the learning activity.

We could go on like this forever, but I’m done with this discussion.


#8

I have to agree strongly with Alistair on his point. The book does confuse me as well. The Person *person example is a perfect example.

Perhaps those of you who can program already cannot distinguish what is confusing or clear to completely beginners. That’s understandable. I have a very high proficiency in desktop publishing apps and it would be difficult for me to explain how to perform certain tasks without assuming some sort of underlying knowledge of how they work. But if I were to write a book on how to do those functions for beginners, I’d strive to avoid confusing the user by skipping over some of the basic explanations. It’s akin to telling someone to just press hot keys to get to the tools without explaining which tool they’re selecting or what it does.

This book has a lot of these types of syntacticly confusing examples. When you write Person *person = [[Person alloc] init]; it’s not clear why the two words are the same except for capitalization. I would have preferred a completely different instance name just so there’s no confusion.

I’m currently in Chapter 19 and specifically here because I don’t understand the asterisking conventions in this chapter.


#9

That should be syntax. Programming languages do not prescribe conventions; they operate with syntax and semantics. Conventions are merely cultural artefacts.

As for the Person *person variable declaration, following will help to demystify:

  • A variable declaration consists of two identifiers and some optional qualifiers. In the person example, identifiers are Person and person and the qualifier is the pointer qualifier *.
  • Syntax: identifier optional-qualifier identifier
    The first identifier designates the type; the second name of the variable. As long as the type is defined and the variable name is unique in the scope in which the declaration appears, variable name can be anything (probably not a type identifier.)

#10

That should be syntax. Programming languages do not prescribe conventions; they operate with syntax and semantics. Conventions are merely cultural artefacts.

As for the Person *person variable declaration, following will help to demystify:

  • A variable declaration consists of two identifiers and some optional qualifiers. In the person example, identifiers are Person and person and the qualifier is the pointer qualifier *.
  • Syntax: identifier optional-qualifier identifier
    The first identifier designates the type; the second name of the variable. As long as the type is defined and the variable name is unique in the scope in which the declaration appears, variable name can be anything (probably not a type identifier.)[/quote]
    Thanks for the explanation. I understand the Person *person part now because I went back and reread the book because I felt like I was understanding less and less of each progressive lesson. The fact that the variable name can be anything is what I think Alistair and I are having an issue with. I understand how it could be construed as being clearer to create a variable that’s the same word as the type, I feel it’s the opposite. If it read Person *thisIsSomePerson I would have understood it better than Person *person. The second way, and the way it is written in the book, leaves one to consider if person serves the same purpose Person.

For me, I was also confused earlier on when one of the variables had different punctuation because of the set function (ie, variable name: theVariable. setTheVariable). I guess I had assumed there was case-sensitivity because of the way the variable names are written.

Overall, I like the book a lot and I think it’s generally well-paced and explained. But there are a few areas where there is a gap in explanation. This chapter is one of the areas. That’s why I’m doing the research on here and stack overload to figure out the syntax of this chapter.


#11

I think that even though the guy is trying to help, and believe me any help from anyone while in the early stages of learning code etc is truly appreciated, ibex10’s answers I feel are unnecessarily convoluted and at times I’ve felt like throwing my laptop out the window just trying to read and understand ‘what the hedge’ he is trying to explain to us mere mortals. Its like a getting answers from a machine rather than a man lol
The truth I’ve learnt in 7 months of constant study is that this stuff is truly easy to learn one step at a time as long as you are ‘having programming concepts taught in a specific, beginner friendly manner and associating these concepts with what we may already know about and are familiar with in life’.
When I get to a point of understanding a particular concept in the software dev world I can explain it to a 10 year old, no problems… This should be the case with all beginner materials…

I used to also believe, out of ignorance, that the software dev world is for truly smart and intelligent people but it really doesn’t require this supremely intelligent person to understand and be able to write programs but rather someone who has been taught the right way with the correct examples.

There is a lot to learn and remember and that takes time so please teachers and guides remember this when you are helping us. Your help is extremely important to us and we need you but please don’t make learning more complicated than it has to be.
Thanks


#12

There is no need to throw objects out the window because somebody might get hurt. That machine is capable of understanding intelligent questions and responding accordingly.


#13

Haha! I don’t doubt it…!
Truth is, I secretly idolise you ibex10. :wink:


#14

The funny thing about all of this is that the syntax of Objective C was designed to be “literal”.

Hence the very long function names which are supposed to get the programmer closer to “natural language”.

But it happens to be exactly the contrary: many specialists and teachers of Objective C do recognize that they have had much difficulty to wrap their minds around Objective C.

Many, if not all, recommend experienced programmers to throw all their previous knowledge through the window because any attempt to associate what they know (C, Basic, VBA, whatever) and what they are trying to learn (Objective C) will only hinder, if not make impossible, their comprehension of Objective C.

There would be much to say about all of this, but, at the end of the day, I get it: shut up and put up…

Still, there is no freaking reason to make an already daunting task an excruciating one.

As a teacher, one is supposed to make things so that learning is optimized.

The BNR, IMO, has been the most successful so far in teaching it.

Still: making things easier would be, heck, easier.