Operator overloading (hello, php)

About Monkey 2 Forums Monkey 2 Programming Help Operator overloading (hello, php)

This topic contains 10 replies, has 4 voices, and was last updated by  cocon 1 month, 4 weeks ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #13361

    nerobot
    Participant

    I’m working with PHP last time, and there is a nice array syntax:

    arr[] = "hello";

    that means append the string to array.

    I tried to achive that in Monkey2. 🙂

    I set default value of key to Null hoping to be able to omit key, but with no luck:

    result is:

    Error : Expecting expression but encountered ']'

    It’s impossible, I think, and looks like just as academic try. 🙂

    #13364

    cocon
    Participant

    You refer to this one right?
    http://php.net/manual/en/function.array-push.php

    From what I have tested up until now, in Monkey the operator [] as a language construct is specified to work as an indexer (which is similar to a C# concept). http://monkeycoder.co.nz/forums/topic/some-indexers-for-lists/

    You can think of the indexer function signatures (if you assume that there is no operators at all) similar to this:

    Where in this example you can see how this concept would possible work, but be aware that this is only an example for the Joy-Of-API-Hacking and satisfy the compiler.

     

    Also for the record, @hezkore found a way of changing the fundamental datatypes, perhaps you would be interested to see how you can change the meaning of the [] operator with this one, I haven’t tried something like this yet to be sure but it seems interesting. 🙂
    https://github.com/Hezkore/m2stp/blob/master/inc/base_functions.monkey2

    #13369

    Mark Sibly
    Keymaster

    that means append the string to array.

    It sure doesn’t look like it!

    This would require major changers to the parser though, as ‘[]’ is not a valid ‘value expression’ (it may only appear in type expressions, ie: when declaring the type of something).

    How about ‘+=’ instead? This looks much more logical to me.

    #13379

    nerobot
    Participant

    You refer to this one right?

    Yes. Your example is not good enough because I want to omit the key at all.

    Also, if you pass False as a string parameter, you’ll get the string “False”, not an empty string,

    and expression If key then... always be true.

    I think you mean to pass Null here.

     

    How about ‘+=’ instead? This looks much more logical to me.

    It seems to be the only way here. 🙂

    Brackets show us we deal with array, but += don’t.

    But I don’t expect to break parser and our minds just because the PHP syntax. 🙂

    #13381

    Mark Sibly
    Keymaster

    Brackets show us we deal with array, but += don’t.

    That’s about all it shows. The syntax ‘[]=’ to append to an array is typical php WTF-ness!

    But I did have a quick look at the parser and, I sort of hate to say it, but it’s actually a pretty simple tweak to allow no args for array indexing. With a 2 line change to parser.monkey2 I can compile this…

    …which isn’t quite what you wanted, but enough to be able to do what you want I believe?

    I still really dislike []= to append to an array though, boring old Method Add() is IMO a much better option!

    #13384

    nerobot
    Participant

    Wow, good news!

    When you omit key it passes as Null ?

    #13386

    Diffrenzy
    Keymaster

    That’s about all it shows. The syntax ‘[]=’ to append to an array is typical php WTF-ness!

    I agree. += is nice though.

    #15521

    nerobot
    Participant

    I’m thinking about assignment operator, again 🙂

    And it would be enough for me to have []= operator as a special kind of assignment.

    This time both of these operators don’t work.

    and this sounds interesting:

    With a 2 line change to parser.monkey2 I can compile this

    What are anyone think about it?:)

    As for me – it could be a part of language, we don’t need to use it every time…

    #15523

    Mark Sibly
    Keymaster

    Yeah, nah…

    Sorry, but it still looks kind of nasty to me. And aren’t you gonna  confuse a whole bunch of php users?!?

    I’m probably not quite as adverse to overloading ‘=’ as I used to be though. I assume the goal here is still to achieve ‘property changed’ events/signals?

    I mean, you can already do this quite easily:

    …but of course you know this! If the goal is to wrap both the signal and the setter/getter in a single concept, you can do this too, eg:

    This is effectively what your (mostly) doing above, except you need to use Lifestyle.Set() and Lifestyle.Get() to set/get the value, plus you can listen for changes using Lifestyle.Changed+=Lamba…

    IMO, the []= syntax isn’t enough of an improvement over plain Set and Get here to justify it. In fact I’d argue Get and Set is much clearer than an ‘array looking’ operator. And either way, the programmer has to ‘know’ to use it (if you see what I mean).

    Overloading ‘=’ is much more interesting though – it means ‘live’ properties like this could be added to existing code without user code knowing it wasn’t just reading/writing files/properties. But for this work, there’d also have to be a ‘conversion’ operators for reads. Perhaps something like:

    But alas we’ve already hit our first complication! If the ‘type’ of Lifestyle is Int thanks to its getter operator, how can we access Lifestyle.Changed?

    And if T is a class/struct, what does Lifestyle.blah mean? Is it a member of Lifestyle, or a member of LifeStyle.Getter? The compiler could attempt to guess what you want to do, but it’d likely result in a bunch of confusing rules, and type conversions would be a nightmare when calling functions, assigning to vars etc. And what happens with prop1=prop2? If they are both Int Getters of the same type, should it get/set the int, or assign the entire getter, ‘Changed’ listeners and all? The sensible thing to do in all these cases is probably to treat any value  with a Getter as a value of the Getters type instead (just like properties),  and add new syntax to somehow ‘ignore’ the getter when you want work with the actual property-like container.

    All in all it’s an interesting idea and I think it could be made to work, will keep thinking about it….

    #15524

    nerobot
    Participant

    And aren’t you gonna  confuse a whole bunch of php users?!?

    agree, it’s very bad idea. 🙂

    If the ‘type’ of Lifestyle is Int thanks to its getter operator, how can we access Lifestyle.Changed?

    yes! it’s looks impossible, and I miss it in my minds, if we have getter that return any type – we cant easily access to our parent type,

    the way via casting is not what we want.

    And what happens with prop1=prop2? If they are both Int Getters of the same type, should it get/set the int, or assign the entire getter, ‘Changed’ listeners and all? The sensible thing to do in all these cases is probably to treat any value  with a Getter as a value of the Getters type instead (just like properties),  and add new syntax to somehow ‘ignore’ the getter when you want work with the actual property-like container.

    I expected to have type conversion for expressions with our type, but not for dot access case, but I see now that it’s kind of impossible. 🙂

    Even if we’ll have assignment operator we’ll have no proper get operator and need to write getter explicitly:

    Operator To:T can help in some cases but not all.

    And I think now that using explicit prop.Value for setter and getter is the best solution.

    Thanks for the detailed answer, Mark!

    #15527

    cocon
    Participant

    Something else theoretical, if we had the ability to declare custom operators as in Haskell, we would simply use them in interesting ways.

     

    As for example let’s say we would like to have the initial idea of nerobot to append strings. We would write this pure function, “pure” means that the function is stateless (state-independent).

    OK, we might consider that this code is dump pointless 🙂 . Now taking concept further we would avoid this once and for all and use this instead.

    The general idea of using custom operators is to reduce “verbose” syntax. Instead of having a pumped API that makes you bored to hell to use it. You would cleverly create important domain operations and thus create such shortcuts.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.