<div dir="ltr">Hmmm...<div><br></div><div><span style="font-size:12.8px">Richard has a point...</span><br></div><div><span style="font-size:12.8px">What are the ETH thoughts about it?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Is it because, since we have different applications here, </span><span style="font-size:12.8px">Edit and Draw;</span><span style="font-size:12.8px"> hence different Store commands? Most likely...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It seems good, to have one Store command.</span></div><div><span style="font-size:12.8px">But shall we unify everything on a GUI machinery?</span></div><div><span style="font-size:12.8px">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?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I think this will be the extreme use of OO...</span></div><div><span style="font-size:12.8px">But to be frank, this is also not rare...</span></div><div><span style="font-size:12.8px">Now a days most IDEs are like this, example Visual Studio.</span></div><div>This may be handling dozens or more kind of documents and having only one Save button hanging from File->Save. :-D</div><div><br></div><div class="gmail_extra"><br><div class="gmail_signature"><div>With thanks and best regards,</div><div> </div><div>Yours sincerely,</div><div>Srinivas Nayak</div><div> </div><div>Home: <a href="http://www.mathmeth.com/sn/" target="_blank">http://www.mathmeth.com/sn/</a><br>Blog: <a href="http://srinivas-nayak.blogspot.in/" target="_blank">http://srinivas-nayak.blogspot.in/</a></div><div><br></div><div><br></div></div><div class="gmail_quote">On Mon, Mar 6, 2017 at 3:26 AM, Richard Hable <span dir="ltr"><<a href="mailto:informujo@aon.at" target="_blank">informujo@aon.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 2017-03-03 um 11:40 schrieb Andreas Pirklbauer:<br>
<br>
> That is exactly right: There are indeed no type extensions in the<br>
> Oberon "inner core" (modules Kernel, FileDir, Files and Modules). And<br>
> almost no type extensions in the "outer core" (modules Input,<br>
> Display, Viewers, Fonts, Texts, Oberon). The one exception I found is<br>
> in module Texts<br>
<br>
I think, it would actually be a good thing to have more object<br>
orientation also in the core modules. It could make the system less<br>
static and more adaptable and user friendly.<br>
<br>
For example, if module TextFrames contained type-bound procedures based<br>
on the Frame type instead of a collection of static procedures with a<br>
Frame parameter, one could easily adapt its behavior by overriding just<br>
a few selected procedures.<br>
<br>
And if all documents were based on a common type with overridable<br>
type-bound command procedures, the user would not have to choose between<br>
commands like "Edit.Store" and "Draw.Store", but simply invoke "Store",<br>
which would automatically call the right procedure according to the<br>
actual document type.<br>
<br>
Richard<br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><br>
</blockquote></div><br><br clear="all"><div><br></div><div class="gmail_signature"><div><br></div><div> </div></div>
</div></div>