OpenEuphoria

2. Re: Phix syntax

• Posted by petelomax Dec 18, 2020
• 1025 views
• Last edited Dec 22, 2020

That's not an entirely mad idea.

As you say, if name is public, then w.name operates as normal and doesn't invoke any "magic", and I wouldn't change that.

At the moment, if name is private, it is a runtime error, which is too late to do anything about it.
If I first changed it, as I probably should, to a compile-time error, that could open up further possibilities.
It could, just before issuing such an error, check for (public) get_name/set_name methods and invoke those instead,
or to be pedantic about it, emit the appropriate code to invoke them/pretend they'd been written that way.

I don't think it would need any specific syntax, accessing a private xyz would make it look, depending on context,
for either a single parameter (and public) set_xyz procedure, or a parameter-less get_xyz function.

Note that w["name"] style access wouldn't change.

4. Re: Phix syntax

• Posted by petelomax Dec 19, 2020
• 960 views

It doesn't, you've found a bug (thanks).

If you declare a second name field, as expected you get a "duplicate" compilation error.

However all methods are "virtual", in the sense that they can be overidden.
If your base Widget class has a set_name() procedure, and your Window class also has one, it quietly replaces it.
(And before you ask, there isn't any kind of super.get_name(), or any firm plans to add such, as yet.)
(For now, I'd just suggest putting any such code in a private get_name_() and invoking that directly, twice.)
The bug(s) are: it should check that any such replacement has the right type/signature, and that whatever it is
replacing is from an extended/base class rather than the current one. As it stands, those declarations store an
integer routine_id in the string name[1], and you'd need a bit of indirection/sleight of hand to fake out the
compiler such that you could invoke (the second) via call_func (the procedure's routine_id has already been lost).

[1] Technically, that is, in the default for the name field, ie some internal {0,"",3074} ==> {0,3076,3074}, so
it is neatly sidestepping all the usual builtin typechecking mechanisms, and of course new() totally trusts the
integrity of said internal.

PS. I'm committed to this idea now, but with no timescale as yet.

6. Phix-EuGTK development

• Posted by Senator Dec 21, 2020
• 867 views

Irv,

Just to be clear - your Phix-EuGTK development platform is Linux, yes?

If Linux is still your development platform please tell us your current distribution and release (again).

Your patience is appreciated. I will certainly give Linux/Phix+EuGTK a closer look, if you are able to pull off the port (is port the correct term?).

Thanks again for your ongoing development of EuGTK and thanks to Pete for his ongoing development of Phix.

Regards, Ken

8. Re: Phix syntax

• Posted by petelomax Dec 22, 2020
• 863 views

I don't half spout some twaddle sometimes, so glad I slept on this before jumping straight in.

First, a minor fix to builtins\get_routine_info.e, function get_routine_info() line 49, replace

    string name = sr[S_Name] 
--  object name = sr[S_Name] 

with

--  string name = sr[S_Name] 
    object name = sr[S_Name]    -- 22/12/20 class methods have a [symtab] name of -1, on purpose 
                                --          (their proper names are kept in builtins/structs.e, 
                                --           and are passed in as text anyway, so you don't need 
                                --           multiple conflicting entries messing up the symtab, 
                                --           or ever allow a "do()" that should be an "s.do()".) 

I have updated the docs to mention that class methods return a name of -1.

In builtins/structs.e, procedure store_field() (line 1048), replace

                if cdii=NULL or not find(context,cdii) then 
                    crash("attempt to modify private field (%s)",{field_name},2) 
                end if 

with

                if cdii=NULL or not find(context,cdii) then 
                    -- 22/12/20 (setter handling) 
                    if stype<=S_CLASS then 
                        integer setter = field_dx(sdx,"set_"&field_name) 
                        if setter!=0 then 
                            integer flags = structs[sdx][S_FIELDS][setter][S_FLAGS] 
                            if flags=SF_PROC then -- (and not SF_PRIVATE, obvs) 
                                integer setfn = instances[sdx][C_INSTANCES][s[I_DATA]][setter] 
                                {integer maxp, integer minp, string sig} = get_routine_info(setfn) 
                                if maxp>=2 and minp<=2 and sig[1..2] = "PO" then 
                                    call_proc(setfn,{s,v}) -- (this,v) 
                                    return 
                                end if 
                            end if 
                        end if 
                    end if 
                    crash("attempt to modify private field (%s)",{field_name},2) 
                end if 

And just a bit further down, in function fetch_field(), replace

        if not sequence(cdii) 
        or not find(context,cdii) then 
            crash("attempt to read private field (%s)",{field_name},2) 
        end if 

with

        if not sequence(cdii) 
        or not find(context,cdii) then 
            -- 22/12/20 (getter handling) 
            if stype<=S_CLASS then 
                integer getter = field_dx(sdx,"get_"&field_name) 
                if getter!=0 then 
                    integer flags = structs[sdx][S_FIELDS][getter][S_FLAGS] 
                    if flags=SF_FUNC then -- (and not SF_PRIVATE, obvs) 
                        integer getfn = instances[sdx][C_INSTANCES][s[I_DATA]][getter] 
                        {integer maxp, integer minp, string sig} = get_routine_info(getfn) 
                        if maxp>=1 and minp<=1 and sig[1..2] = "FO" then 
                            return call_func(getfn,{s}) -- (this) 
                        end if 
                    end if 
                end if 
            end if 
            crash("attempt to read private field (%s)",{field_name},2) 
        end if 

If attempting to fetch or modify a private field would otherwise trigger a fatal error, but
there is a suitable public get_field function or set_field procedure, it is invoked instead.
Note that getters and setters do not work inside class methods, otherwise we would have
eg get_field() invoking itself ad infinitum instead of just fetching the field directly.
You can of course call any such getters and setters directly.

Example:

class test 
    private string s = "1" 
 
    public function get_s() 
        printf(1,"get_s() called\n") 
        return s 
    end function 
 
    public procedure set_s(string v) 
        printf(1,"set_s(%s) called\n",v) 
        s = v 
    end procedure 
end class 
 
test t = new() 
?t.s        -- get_s() called, "1" 
t.s = "2"   -- set_s(2) called 
?t.s        -- get_s() called, "2" 

10. Re: Phix syntax

• Posted by petelomax Dec 22, 2020
• 844 views

Actually they do. There are two catches:
1) you don't use routine_id, it's already there for you
2) you have to explicitly provide a "this" as first parameter on the call_func/proc.

This works fine for me (outside the class):

?w.handle  -- 18 
call_proc(w.set_handle,{w,19}) -- same as w.set_handle(19) 
?w.handle  -- 19 

12. Re: Phix syntax

• Posted by petelomax Dec 22, 2020
• 837 views

True. Do this:

--                              {integer maxp, integer minp, string sig} = get_routine_info(setfn) 
--                              if maxp>=2 and minp<=2 and sig[1..2] = "PO" then 
                                    call_proc(setfn,{s,v}) -- (this,v) 
                                    return 
--                              end if 
 
--                      {integer maxp, integer minp, string sig} = get_routine_info(getfn) 
--                      if maxp>=1 and minp<=1 and sig[1..2] = "FO" then 
                            return call_func(getfn,{s}) -- (this) 
--                      end if 

It will then trust to luck a bit, that you haven't given it a procedure get_field or a function set_field. Mind you, it'll crash if needed anyway.

I'll have to probably should figure out some way to turn that off during compilation (it's stomping on the symbol table!) but back on at runtime.

EDIT: I've now successfully disabled get_routine_info() during compilation, which needed removal of the long-broken instruction scheduler, which was about time and like 2000+ edits...