[Oberon] Class Methods Vs. Procedure variables in Records

Srinivas Nayak sinu.nayak2001 at gmail.com
Tue Mar 7 08:12:47 CET 2017


Hmmm...

Richard has a point...
What are the ETH thoughts about it?

Is it because, since we have different applications here, Edit and Draw; hence
different Store commands? Most likely...

It seems good, to have one Store command.
But shall we unify everything on a GUI machinery?
Shall we imagine only one Save button on a Windows desktop, which will save
any kind of file opened on any application, finding the actual application
object from the active window?

I think this will be the extreme use of OO...
But to be frank, this is also not rare...
Now a days most IDEs are like this, example Visual Studio.
This may be handling dozens or more kind of documents and having only one
Save button hanging from File->Save. :-D


With thanks and best regards,

Yours sincerely,
Srinivas Nayak

Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/


On Mon, Mar 6, 2017 at 3:26 AM, Richard Hable <informujo at aon.at> wrote:

> Am 2017-03-03 um 11:40 schrieb Andreas Pirklbauer:
>
> > That is exactly right: There are indeed no type extensions in the
> > Oberon "inner core" (modules Kernel, FileDir, Files and Modules). And
> > almost no type extensions in the "outer core" (modules Input,
> > Display, Viewers, Fonts, Texts, Oberon). The one exception I found is
> > in module Texts
>
> I think, it would actually be a good thing to have more object
> orientation also in the core modules. It could make the system less
> static and more adaptable and user friendly.
>
> For example, if module TextFrames contained type-bound procedures based
> on the Frame type instead of a collection of static procedures with a
> Frame parameter, one could easily adapt its behavior by overriding just
> a few selected procedures.
>
> And if all documents were based on a common type with overridable
> type-bound command procedures, the user would not have to choose between
> commands like "Edit.Store" and "Draw.Store", but simply invoke "Store",
> which would automatically call the right procedure according to the
> actual document type.
>
> Richard
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170307/a84e84ba/attachment.html>


More information about the Oberon mailing list