Topic-Organized Object-Oriented Programming

I propose an extension to object-oriented programming: topic-organized
object-oriented programming.

It is, simply, classifying all of a class' member variables and member
functions into hierarchical categories by topic.

Member variables and functions under the same topic tend to be invoked
closely. Therefore, if the class manufacturer explicitly declares
which variables and functions are in the same category, it could help
the compiler to optimize user programs which make use of this class,
because loading of data and code in categories unrelated to the
currently active category can be delayed, while data and code right in
or related to the currently activated category can be preloaded and
pre-initialized.

Organization by topic also helps in the coding phase because the class
user no longer has to face a very long list of member functions and
variables when he enters the name of an object instantialized by this
class. He can specify the "currently active topic" and only see
members belonging to this topic. He could switch to a related topic by
following a link designed by the class manufacturer. For example,
suppose the class is "Human" (a class with member functions
corresponding to almost every conceivable verb) and the currently
active topic is "Car Accident", related topics could be causal-
relation topics such as "Hospitalization" and "Lawsuit".

Regards,
Yao Ziyuan

Booted Cat wrote:
> I propose an extension to object-oriented programming: topic-organized
> object-oriented programming.
>
> It is, simply, classifying all of a class' member variables and member
> functions into hierarchical categories by topic.

Trees are usually a poor categorization structures beyond the trivial.
I suggest you read:

http://c2.com/cgi/wiki?LimitsOfHierarchies

I find sets a much more powerful categorization tool. I agree they can
take longer to get one's head around, but power does not always come
cheap.


>
> Member variables and functions under the same topic tend to be invoked
> closely. Therefore, if the class manufacturer explicitly declares
> which variables and functions are in the same category, it could help
> the compiler to optimize user programs which make use of this class,
> because loading of data and code in categories unrelated to the
> currently active category can be delayed, while data and code right in
> or related to the currently activated category can be preloaded and
> pre-initialized.
>
> Organization by topic also helps in the coding phase because the class
> user no longer has to face a very long list of member functions and
> variables when he enters the name of an object instantialized by this
> class. He can specify the "currently active topic" and only see
> members belonging to this topic. He could switch to a related topic by
> following a link designed by the class manufacturer. For example,
> suppose the class is "Human" (a class with member functions
> corresponding to almost every conceivable verb) and the currently
> active topic is "Car Accident", related topics could be causal-
> relation topics such as "Hospitalization" and "Lawsuit".
>
> Regards,
> Yao Ziyuan

-T-
oop.ismad.com

"Booted Cat" <yaoziyuan{}> wrote in message
news:1170864021.615170.156400{}v33g2000cwv.googleg roups.com...
>I propose an extension to object-oriented programming: topic-organized
> object-oriented programming.
>
> It is, simply, classifying all of a class' member variables and member
> functions into hierarchical categories by topic.

If you find yourself wanting to classify members by categories you probably
need to ask the question whether your class should be broken up into smaller
classes.

Andrew

Most Smalltalk implementations do that already for methods. A class'
methods can be put into categories called protocols, and idioms exist
for protocol names.

For instance, methods under the "accessing" protocol are typically
getters and setters. "initialize-release" includes methods for, well,
initializing the object and releasing it. Methods the class' author
would rather people not use or play with usually have the word "private"
attached to them. The intent of private protocols is that the author
wants to warn potential users the method was not intended for public use.

On the class side, there is often a protocol named "instance creation"
which would list the methods users can use to create instances of the
class in various forms.

As the use and naming of protocols is fairly consistent, Smalltalk
programmers know what to look for when they're first examining a class
to learn how they might use it.

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

DAG is always an intuitive generalization of tree.

On Feb 8, 6:09 am, "Booted Cat" <yaoziy...{}> wrote:

> DAG is always an intuitive generalization of tree.

You have to ignore Topmind on this topic.

He lives in some deluded fantasy world where the OO type regime is
based on trees, when it is as you have stated based on graphs. He
then tries to base much of his anti-OO rants on this delusion.

We dare not throw in currently available type substitution regimes
because that would shatter his 'set-based is better and OO cannot
do that' rants too (could book him a place in the looney-bin) ... :-)


Regards,
Steven Perryman

On Feb 7, 4:00 pm, "Booted Cat" <yaoziy...{}> wrote:

> I propose an extension to object-oriented programming: topic-organized
> object-oriented programming.

> It is, simply, classifying all of a class' member variables and member
> functions into hierarchical categories by topic.

> Member variables and functions under the same topic tend to be invoked
> closely. Therefore, if the class manufacturer explicitly declares
> which variables and functions are in the same category, it could help
> the compiler to optimize user programs which make use of this class,
> because loading of data and code in categories unrelated to the
> currently active category can be delayed, while data and code right in
> or related to the currently activated category can be preloaded and
> pre-initialized.

> Organization by topic also helps in the coding phase because the class
> user no longer has to face a very long list of member functions and
> variables when he enters the name of an object instantialized by this
> class. He can specify the "currently active topic" and only see
> members belonging to this topic. He could switch to a related topic by
> following a link designed by the class manufacturer. For example,
> suppose the class is "Human" (a class with member functions
> corresponding to almost every conceivable verb) and the currently
> active topic is "Car Accident", related topics could be causal-
> relation topics such as "Hospitalization" and "Lawsuit".

Work in this area has been done (see things like IBM "hyper-
slices" ) .

There are cosmetic organisation constructs (Eiffel, Smalltalk etc)
that are
used for categorisation, but AFAIK have no semantic value such as type
checking (although Eiffel for all I know might be able to set class
property
access based on category name etc).

I think the semantic support of categories would be good.
For example, for a type T you might have a category "const" .
Being able to define a type ref as T{const} etc would IMHO be very
elegant.

Categories can be defined as someone sees fit.
And the type (substitutability) regimes that OO uses will easily
support such a
concept.


Regards,
Steven Perryman

On Feb 7, 7:00 pm, "Booted Cat" <yaoziy...{}> wrote:
> I propose an extension to object-oriented programming: topic-organized
> object-oriented programming.
>
> It is, simply, classifying all of a class' member variables and member
> functions into hierarchical categories by topic.
>
> Member variables and functions under the same topic tend to be invoked
> closely. Therefore, if the class manufacturer explicitly declares
> which variables and functions are in the same category, it could help
> the compiler to optimize user programs which make use of this class,
> because loading of data and code in categories unrelated to the
> currently active category can be delayed, while data and code right in
> or related to the currently activated category can be preloaded and
> pre-initialized.
>
> Organization by topic also helps in the coding phase because the class
> user no longer has to face a very long list of member functions and
> variables when he enters the name of an object instantialized by this
> class. He can specify the "currently active topic" and only see
> members belonging to this topic. He could switch to a related topic by
> following a link designed by the class manufacturer. For example,
> suppose the class is "Human" (a class with member functions
> corresponding to almost every conceivable verb) and the currently
> active topic is "Car Accident", related topics could be causal-
> relation topics such as "Hospitalization" and "Lawsuit".
>
> Regards,
> Yao Ziyuan

It is not new idea. Someone mentioned the IBM project already, but
that project is long dead.

The most comprehensive study is in the following PhD thesis on this
matter:

http://www.dcs.shef.ac.uk/~ajhs/research/thesis/

Also check out the "partial classes" of C# language, which is trying
to slice modules.

On Feb 8, 12:31 am, ggro...{}bigfoot.com wrote:
> On Feb 8, 6:09 am, "Booted Cat" <yaoziy...{}> wrote:
>
> > DAG is always an intuitive generalization of tree.
>
> You have to ignore Topmind on this topic.
>
> He lives in some deluded fantasy world where the OO type regime is
> based on trees, when it is as you have stated based on graphs. He
> then tries to base much of his anti-OO rants on this delusion.

Is your rudeness necessary?

The original author was not necessarily talking about OO, but
classification trees. I did not imply tree/hierarchy, it was
EXPLICITLY stated by the author of the message.

As far as OO and trees, this blurb from my webpage summarizes it:

"OOP proponents are stuck between a rock and a hard place. If they
rely on hierarchies, then they have to face the many limits of
hierarchies. If they don't, then they rely on the chaotic pointer-like
hell of navigational structures that were discredited in the 1970's."

>
> We dare not throw in currently available type substitution regimes
> because that would shatter his 'set-based is better and OO cannot
> do that' rants too (could book him a place in the looney-bin) ... :-)

OO is not required to have types, let alone substitutable types. But
yes, one can *add* sets to OO, but it can be added to any paradigm or
language if one bothers to write libraries or language extensions. But
OO *itself* is not based on sets, and that is a drawback of OO.

>
> Regards,
> Steven Perryman

-T-

On Feb 8, 12:31 am, ggro...{}bigfoot.com wrote:
> On Feb 8, 6:09 am, "Booted Cat" <yaoziy...{}> wrote:
>
> > DAG is always an intuitive generalization of tree.
>
> You have to ignore Topmind on this topic.
>
> He lives in some deluded fantasy world where the OO type regime is
> based on trees, when it is as you have stated based on graphs. He
> then tries to base much of his anti-OO rants on this delusion.

Is your rudeness necessary?

The original author was not necessarily talking about OO, but
classification trees. I did not imply tree/hierarchy, it was
EXPLICITLY stated by the author of the message.

As far as OO and trees, this blurb from my webpage summarizes it:

"OOP proponents are stuck between a rock and a hard place. If they
rely on hierarchies, then they have to face the many limits of
hierarchies. If they don't, then they rely on the chaotic pointer-like
hell of navigational structures that were discredited in the 1970's."

>
> We dare not throw in currently available type substitution regimes
> because that would shatter his 'set-based is better and OO cannot
> do that' rants too (could book him a place in the looney-bin) ... :-)

OO is not required to have types, let alone substitutable types. But
yes, one can *add* sets to OO, but it can be added to any paradigm or
language if one bothers to write libraries or language extensions. But
OO *itself* is not based on sets, and that is a drawback of OO.

>
> Regards,
> Steven Perryman

-T-