[Oorexx-rfes] [ oorexx-Feature Requests-1151299 ] Allow removal of methods in subclasses

[SourceForge.net <no...@so...>]

Feature Requests item #1151299, was opened at 2005-02-24 14:40
Message generated for change (Comment added) made by bigrixx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1151299&group_id=119701

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Classes
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Rony G. Flatscher (orexx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow removal of methods in subclasses

Initial Comment:
Sometimes a specialisation of an existing class may
actually loose a specific behaviour (method), which may
be available in its superclass(es).

E.g. if birds are modeled that they are able to fly
(have a method "FLY" defined), then specialisations may
loose that ability (e.g. an ostrich, which is able to
run, but cannot fly anymore).

For such situations allow to remove a method from being
inherited by a subclass. I.e. using normal method
lookup would treat such a removed method as unknown.

Possible syntax:

::method FLY remove


----------------------------------------------------------------------

>Comment By: Rick McGuire (bigrixx)
Date: 2008-08-15 20:13

Message:
Logged In: YES 
user_id=1125291
Originator: NO

This is not good oo practice, and can seriously mess up code that is
expecting that an isA test returning true implies that a class supports
given methods.  If you really wish to have this be an error, then you can
use the RAISE instruction to force the error, but this is not something
that belongs are part of the base object model. 

----------------------------------------------------------------------

Comment By: Rony G. Flatscher (orexx)
Date: 2007-06-02 17:59

Message:
Logged In: YES 
user_id=662126
Originator: YES

Actually, I think using the name 'UNDEFINE' allows this feature to be
applied in the general case (but also to the aforementioned case).

E.g. this could then be applied to those methods that raise a 93.963 error
in "InputStream" (charOut, lineOut, position), "OutputStream" (charIn,
chars, lineIn, lines, position) and "InputOutputStream" (position). [These
classes got added in rev. 373.]

One would then write for 'InputStream':

::class 'InputStream'
::method 'charIn'     abstract
::method 'charOut'    undefine
::method 'chars'      abstract
::method 'lineIn'     abstract
::method 'lineOut'    undefine

Sending then a message 'charIn' to an 'InputStream' object raise error
93.963.

This particular error should be treated like the 97.1 ('Object method not
found') error (it is a sort of a close "relative" to it), such that the
unknown mechanism could be used to programmatically to intercept this
family of errors. In that case, it may make sense to use a new error number
out of # 97 like '97.2' instead of '93.963', giving a text like "Method 'm'
has been undefined and is not available to object 'o'."


----------------------------------------------------------------------

Comment By: Rony G. Flatscher (orexx)
Date: 2007-04-16 03:30

Message:
Logged In: YES 
user_id=662126
Originator: YES

The suggested REMOVE option on a method directive

   ::METHOD fly REMOVE

could be probably realized with SETMETHOD() at object initialization time
(maybe in the Class' NEW method, before sending the INIT message to the
freshly created object)?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1151299&group_id=119701