Re: Unresponsive mouseMoved method
Re: Unresponsive mouseMoved method
- Subject: Re: Unresponsive mouseMoved method
- From: Andy Lee <email@hidden>
- Date: Sat, 31 Mar 2007 05:41:58 -0400
On Mar 31, 2007, at 4:11 AM, mmalc crawford wrote:
On Mar 30, 2007, at 11:37 PM, Andy Lee wrote:
I do agree, and I posted the following feedback using the link at
the bottom of the NSView doc page:
The use of the term "abstract class" in the "Class at a Glance"
section can easily confuse people coming from other languages
where the term has a specific meaning. Having used Smalltalk, C+
+, and Java, I think of an abstract class that can't or shouldn't
be instantiated. But it's not only possible but perfectly fine to
instantiate NSView, as proven by CustomViews and tab views in IB.
The problem is compounded by the fact that, as far as I can tell,
the term "abstract class" is not explained anywhere for the
Objective-C/Cocoa context.
The issue isn't really specific to views, of course.
Abstract classes are defined for Obj-C here:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
ObjectiveC/Articles/chapter_4_section_4.html>
Ah, thanks. I didn't find that because I searched for "abstract
class" in the Xcode doc window, with the top-level Reference Library
selected, and the above document was much farther down in the results
than I expected to have to scroll. Changing the search to "abstract
classes" makes it the second hit.
Class clusters are described in terms of the abstract factory
pattern here:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaFundamentals/CocoaDesignPatterns/chapter_5_section_3.html>
this is a different concept but does include a contrast...
(see also <http://developer.apple.com/documentation/Cocoa/
Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_9.html>).
Where would be an appropriate place to make the distinction clear
(in particular where would you expect someone to be likely to read
it)?
First, regarding what I believe was the original post, I would say
the NSView documentation is wrong in calling NSView an abstract
class, and so is any other documentation that says it is, like the
NSFormatter doc. In the "Classes" doc you pointed to above, it says:
- - -
Some classes are designed only so that other classes can inherit from
them. These abstract classes group methods and instance variables
that can be used by a number of different subclasses into a common
definition. The abstract class is incomplete by itself, but contains
useful code that reduces the implementation burden of its subclasses.
- - -
The first and last sentences of this paragraph are false for NSView,
which has perfectly good uses that don't require subclassing.
More generally:
* I admit I didn't try hard enough in my search, but ideally, the
Xcode doc window would have ranked the docs you listed above higher
than the numerous docs for abstract Java classes. What's weird is
that a Google for "abstract classes site:developer.apple.com" <http://
www.google.com/search?q=abstract+classes+site:developer.apple.com>
doesn't find that first "Classes" doc at all -- at least nowhere near
the top. The top hit is the Class Clusters doc you pointed to, which
is also good, but defines "abstract class" implicitly.
* Anywhere a definition is given for "abstract class," like in the
"Classes" doc and in the "Glossary" doc at <http://
developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/
Articles/chapter_999_section_1.html>, it should be pointed out that
abstractness is by convention and is not a language feature. It
should also explain some alternatives to the way other languages
implement abstractness -- for example, delegation and -
forwardInvocation:.
* Because the term is used so much in the "Class Clusters" doc, I
suggest that it include a link to the part of the "Classes" doc that
explains what *we* mean by "abstract class." A Java programmer
coming to that doc might jump to the wrong conclusion about that.
--Andy
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden