Poll: String API Preference

[PurgeandFire]

Out of curiosity, which do you prefer more?

Option A:

call String["Hello"].find("ell")
call String["Hello"].toUpperCase()
set someStr = String[someStringVariable].trim()

(just examples)

Option B:

call String.find("Hello", "ell")
call String.toUpperCase("Hello")
set someStr = String.trim(someStringVariable)

I'm just curious. I can't really tell myself. As for efficiency, the first option is 1 extra function call/set, but it is sort of negligible if you prefer the API that way. It is kinda annoying to type the brackets, but it seems to make sense. The second option is the traditional JASS method, where you just make the "source" string the first parameter.

Thanks.

FAQ: (Frequently Anticipated Questions)

• What about Wurst stdlib?
  
  It is already awesome enough as it is. I'm just curious about it from a vJASS standpoint.

 

[gorillabull]

just out of personal preference a

 

[GhostWolf]

What exactly is option A supposed to be? is String["Hello"] some voodoo object initialization in vJass? because if so, it's the most ugly and ambiguous object initialization I ever saw.

I assume with less ambiguous code it would be something along the lines of

local String s = String("Hello")
call s.find("ell")
// or
String("Hello").find("ell")
// but this is ugly and bad

In this case, I believe most languages actually give access to both - methods of a global object (static functions) and methods for each instance (instance methods)...which are really the same thing, except for the this argument being explicit or implicit.

 

[PurgeandFire]

What exactly is option A supposed to be? is String["Hello"] some voodoo object initialization in vJass? because if so, it's the most ugly and ambiguous object initialization I ever saw.

vJASS allows you to override the operator [] to return an instance from some given "key". For example, let's say you have a struct that is associated with a unit:

struct A
    unit u

    static method create takes unit input returns thistype
        local thistype this = thistype.allocate()
        set this.u = input
        return this
    endmethod
endstruct

And you want to get the instance from the unit. You can store the instance in a table under the unit's ID. Then you can write a method like this:

static method getInstance takes unit u returns thistype
     return SomeTable[GetHandleId(u)]
endmethod

As such, if you want to quickly do an action for a unit's instance, you would end up with something like:

call A.getInstance(u).doSomeAction()

Which is fine, but long. You can always set A.getInstance(u) to a variable, but it is still a little ugly. Alternatively, you can implement an operator to return it, and then you'd end up with:

call A[u].doSomeAction()

Which is considerably cleaner.

It isn't technically initialization though. It is just retrieval. The way it is set up in object A might as well be an initialization though due to the implementation.

I assume with less ambiguous code it would be something along the lines of

local String s = String("Hello")
call s.find("ell")
// or
String("Hello").find("ell")
// but this is ugly and bad

In this case, I believe most interpreted languages actually give access to both - methods of a global object (static functions) and methods for each instance (instance methods)...which are really the same thing, except for the this argument being explicit or implicit.

Yes, sort of. Although, actually having them as objects would take a little extra work and it would serve as different functionality. Right now, consider the two options to be equivalent.

And yeah, that's true. I suppose I could always offer both options. Thanks.

@gorillabull: Thanks.

 

[IcemanBo]

And yeah, that's true. I suppose I could always offer both options. Thanks.

That sounds good. Me also would prefer A maybe, but I guess for a perosn who only codes in normal jass, maybe B seems more familar.

 

[Menag]

Wurst extension functions => A \o/

 

[Magtheridon96]

B bro.

A is syntax sugar abuse.

 

[muzzel]

A is syntax sugar abuse.

#

Id prefer a mix of both, trash the syntax abuse but keep the possibility to "chain" functions, because
stringfun("Hello").toUpper().substring(2, 3).replace("AT", "@")
looks cooler than
replace(substring(toUpper("hello"), 2, 3), "AT", "@")
(Functions are arbitrary examples, no clue what ur implementing)

.. or just use wurst and do

"Hello".toUpper().substring(2, 3).replace("AT", "@")

 

[Adiktuz]

I prefer A

 

[PurgeandFire]

B bro.

A is syntax sugar abuse.

I see what you mean. But syntactic sugar inherently states "abuse me".

#

Id prefer a mix of both, trash the syntax abuse but keep the possibility to "chain" functions, because
stringfun("Hello").toUpper().substring(2, 3).replace("AT", "@")
looks cooler than
replace(substring(toUpper("hello"), 2, 3), "AT", "@")
(Functions are arbitrary examples, no clue what ur implementing)

.. or just use wurst and do

"Hello".toUpper().substring(2, 3).replace("AT", "@")

That'd be nifty if it were possible. I could make it as an object, and then add .str method or something. e.g.:

local String obj = String.create("Hello")
local string s = obj.toUpper().substring(2, 3).replace("AT", "@").str

It could be interesting. It would be annoying to add .str to the end of all your actions, but it is reasonable.

 

[PurplePoot]

I see what you mean. But syntactic sugar inherently states "abuse me".

And this, folks, is why languages shouldn't implement things like operator overloading.

 

[Adiktuz]

wait no actually I prefer B...

though I'd prefer this more

"Hello".find("ell")

 

[GhostWolf]

wait no actually I prefer B...

though I'd prefer this more

"Hello".find("ell")

All types being objects opens the door to many unwanted side effects too, sadly (yes, I am looking at you, Ruby).

 

[Waffle]

a) love the wurst way
b) String(str).method().method().toString()
c) some funky thing that looks like b) but only stores currently manipulated string (efficient but cant store reference to wrapper or blows up in your face)
d) A  It's better than String.fn(str, arg, arg2)  but barely.

 

[Almia]

Sorry to post but.

Shall we put Regex support? It would be awesome.

 

[Adiktuz]

Awesome indeed but IDK if it's useful for wc3

 

[PurgeandFire]

Sorry to post but.

Shall we put Regex support? It would be awesome.

Seems a little overkill to add Regex, especially since only programmers are familiar with it. It would have the same issue as all those data structure snippets.

I suppose it could be useful for really intense chat parsing, but that is about it.

 

[Adiktuz]

but why would we possibly need intense chat parsing?

 

[PurgeandFire]

but why would we possibly need intense chat parsing?

idk. If you want to have advanced reading or filtering or something strange like that. Regex just makes pattern matching and all that shiz a lot easier. But it is rather annoying to implement in Wc3, especially since strings all end up cached in memory.

 

[Zwiebelchen]

I personally don't like operator overloads. So I'd go with B. Just looks cleaner and easier to read for me.

 

[Kazeon]

mine

call String["Hello"].find("ell")
call String["Hello"].toUpperCase()
set someStr = String.trim(someStringVariable)

 

[Magtheridon96]

I'd change my vote to Other if I could.

local integer pos = find_string("Hello", "ell")
local string s = string_to_upper("hi")

 

[PurgeandFire]

ew underscores.

For some reason I have an aversion to them. I've gotten used to them because of python, but they still look ugly compared to camel case, IMO. I guess it depends on whatever you're exposed to first.

I thought about making them all just functions, but it feels so retro.

 

[looking_for_help]

I vote for

local String s = String.create("My String")
call s.substr(0, 5).append("some string").toLower().toUpper()
call BJDebugMsg(s.str())
call s.display() // shorter

 

[Dr Super Good]

B where string is a library and not trying to turn a primitive type into a complex object (which it is not). Wrapping a JASS primitive in a complex object might bring about confusion as to what is native and what needs advanced function calls.

 

[Waffle]

I vote for

local String s = String.create("My String")
call s.substr(0, 5).append("some string").toLower().toUpper()
call BJDebugMsg(s.str())
call s.display() // shorter

i kind of like that.. except i feel that you shouldn't edit the original string..
(or you should like explicitly as for it if you want it)

 

[Almia]

idk. If you want to have advanced reading or filtering or something strange like that. Regex just makes pattern matching and all that shiz a lot easier. But it is rather annoying to implement in Wc3, especially since strings all end up cached in memory.

Mag requested me this months ago.

We could just add String.Match or String.Gsub functionalities to JASS(yes, Im talking about Lua)

 

[Waffle]

i would go for
.matches("regex here") : boolean
.replace("regex", "with plain string") : string // and replaceAll or replace N to go with it possibly..
.indexOf("regex") : int , -1 if not found (might have extra args for start index, or some bool flag for regex/plainstr)