1. [OE] Suggestion for OpenEuphoria 'Next' | Class/Interface/Contract
- Posted by mitgedanken Feb 27, 2021
- 1185 views
Forked from Class/Interface/Contract -- Re: fake class in OE
--[ <built-in> --[+ About An Interface --- --+] interface Class --[ About A Contract -- a "contract name" is optional, -- it is not required to be the same name as the routine or variable. -- could be used for error reporting. -- If a contract is not satisfied an error will occur (aka ##error:crash()##) -- example: (# is like : for namespace. I choose that to differ from namespaces -- i.e. instead of ::) -- sequence message = {Class#contract[_NAME_], Class#contract[_REQUIREMENTS_]} -- crash_message("Contract %s not satisfied!\nRequirements: %s", message) --] contract create atom class_pointer: -1 <= return >= 0 export procedure create() return class_pointer docline "-1 means error, >= 0 means 'This is my pointer and I love you so much!'" end contract --[ About @ --- @ could be a routine name and will be (auto-) called if its Requirements are not satisfied --- I think for ClassError it must be a procedure. --- And the format (fmt) of ##error:crash_message(sequence fmt)## is optional to use --- example: --- fmt could be by default: sprintf("%s is neither %d nor %d", {...}) --- fmt by user would be used like any ##sprintf## i.e. @ClassError("...", {...}) --- See: [["About A Contract"]] --] contract destroy integer code return >= 1 @ClassError -- should it be @ClassError() ?? or return <= 0 @ClassError --- export function destroy() return code docline "<= 0 means no error and >= 1 means an error" end contract --- More (explicit) contracts if needed ... --[ About 'magic routines' -- It's magic if no function was defined -- Like in other languages (Java, etc.) --] export function equal() return boolean export function hash() return sequence export function serialize() return sequence export procedure deserialize() [...] end interface --] interface Animal: Class -- ": Class" is optional, any class/interface/contract/etc. will be inherited from Class contract name sequence name = "Animal" end contract -- Return name of Animal contract export function get_name(): string return name: sequence end contract --- override in an interface is a 'silent' contract: this must be overridden! override function equal() -- should a type-hint be required ?? override function hash() --- end interface class Cow: Animal sequence name = "Cow" export function get_name(): string return name end function export function equal(@Class seq) return equal(seq#name, name) end function export function hash() return name end function end class class Goat: Cow override sequence name = "Goat" [...] end class
Goat#get_name()
class_pointer goat_ = getclass("Goat") -- or get_class("Goat") -- is case-insensitive method_return goat_name = getmethod(goat_, "get_name", {}) -- same here
class_pointer is an atom
method_return is a sequence; {atom class_pointer, sequence method_name, object return_value}
class_pointer goat_ = class:new("Goat") method_return goat_name = class:method(goat_, "get_name", {}) -- or class:call(...) -- or class:func(..) / class:proc(...)
It could be implemented step by step.
The point is to use interfaces and contracts.
Better documentation to read by an IDE/Editor and any human.
The first step could be to ignore 'interface ... end interface'.
It's than a stub. Used for documentation, only.
--[ About "doc...end doc" and "docline" --- I think it's good practice to say which comment is more than a hint for the code owner. --]
2. Re: [OE] Suggestion for OpenEuphoria 'Next' | Class/Interface/Contract
- Posted by irv Feb 27, 2021
- 1151 views
If we are going to have something like doc... end doc, then let's do it right, with embedded html.
It would be fairly easy to make an editor "fold" the doc lines so they wouldn't interfere with actual code editing, and html would allow documentation to be generated with proper appearance and even images.
As it is, wading thru the std libraries trying to find the real code is aggravating.
3. Re: [OE] Suggestion for OpenEuphoria 'Next' | Class/Interface/Contract
- Posted by _tom (admin) Feb 27, 2021
- 1164 views
Nelson's Diamond Lite (see also Diamond)
http://www.rapideuphoria.com/diamondlite.zip
Written for Euphoria3
- the old includes still work (could be upgraded to OE)
- in LSpeedtst.ex must comment out "--tick_rate(100)"
This is a working OOP system.
- I was never a fan of "set_" and "get_" syntax (too much typing.)
- In general, OOP works because of dot notation.
Boechert has shown that using regex you can get nicer OOP syntax with Euphoria. It worked so well he created Bach that had OOP, regex, and IUP built-in; but, no source-code was ever available. This was possibly the ideal Euphoria. It only worked in Windows (so I ignored it). I can't find Bach on the net anymore. The archive does have some early work to show how this could be done.
Conclusion:
- examine Diamond, Bach
- use Phix
be well
_tom
4. Re: [OE] Suggestion for OpenEuphoria 'Next' | Class/Interface/Contract
- Posted by petelomax Feb 27, 2021
- 1125 views
If we are going to ... , then let's do it right, with embedded html.
Except, embedded html is fragmented and scattered in all the wrong places.
You don't make a table and chairs by carving trees still growing in the forest.
If you're going to do it right, start by writing the docs in the right place,
which is anywhere completely and utterly separate from the source code.
Yes, it's common, and yes, it shows. I'm just objecting to incorrect use of "right".
Or maybe you think, say this is really good and somehow actually useful.
5. Re: [OE] Suggestion for OpenEuphoria 'Next' | Class/Interface/Contract
- Posted by katsmeow Feb 27, 2021
- 1123 views
- I was never a fan of "set_" and "get_" syntax (too much typing.)
- In general, OOP works because of dot notation.
Boechert has shown that using regex you can get nicer OOP syntax with Euphoria. It worked so well he created Bach that had OOP, regex, and IUP built-in; but, no source-code was ever available. This was possibly the ideal Euphoria. It only worked in Windows ...
I used "set_" and "get_" only because, like i said, i can't create real stuff in OE's source and then make/compile/whatever. Altho dotted string names and functions can be done, they'd still need to be accessed using keywords that already exist.
I used Bach a bit way back when, it crashed a fair amount. I don't know which version(s) i have, the folder one of them is in is dated 2002. Iirc, Boechert said he wasn't happy with it, and may release better under a non-Bach name. I do not know that he did.
Matt Lewis wrote OOEU, i have versions 1.7.1 , 1.8, and 1.9. It runs on(?) Eu PD v2.5. Iirc, Matt said there were integration issues in OE, and OOEU was not going to be developed.
There was also SOOP, by Mario Steele. It ran on Eu with an include file. Afaik, only one release.
Kat