William Squires wrote:
No, a shared class method should only be able to access a shared class
property, not an instance variable of a specific instance of that class.
After all, it has no knowledge of a specific instance (that's the whole
point), so how could it access an instance variable?
It gets a reference to it. For example, here's a typical factory function:
Shared Function GetWidget(farble As Integer) As Widget
// Return the Widget for the given farble, creating it
// if necessary.
Dim out As Widget = sWidgetMap.Lookup(farble, nil)
if out is nil then
out = New Widget // note: the Widget constructor is protected!
sWidgetMap.Value(farble) = out
end if
out.mGotCount = out.mGotCount + 1 // mGotCount is protected too
return out
End Function
This is all perfectly valid and reasonable, and in fact is a common
idiom: you make the constructor protected, so that it can't be created
from outside the class, and then add a shared function which CAN create
it, but only on terms you specify. (As in the above example, where it
creates a new one only if it doesn't have one already ready to do the
requested job.)
If you want a method of some class to be able to access a protected or
private instance variable of an instance of some other class, then that
class needs to expose it through an accessor method, or a non-default
constructor.
Nope.
The quirk that Karen found is that, if the static type of the
reference is a subclass rather than the base class, code in the base
class is not being allowed access to the base class privates. And
THAT is the bug (or at best, design flaw).
I assume the code in question isn't in an overridden subclass method? If
so, then I would say that's a bug.
Right, it was in a base class method.
Best,
- Joe
--
Joe Strout
Inspiring Applications, Inc.
http://www.InspiringApps.com
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|