Main stream usage

[Petah]

If this were to be used main stream, would it not be better to pick a simpler namespace?

\z\parse_url()
\url\parse()
\arr\key_exists()

[nkkollaw]

@Petah we're not looking to change the API at the moment, just make it consistent.

The goal is for the user to be able to guess what Zubr's equivalent will be from the original function.

EDIT: sorry, do you mean just changing the namespace from "Zurb" to "z", not to group functions in different namespaces?

Sent from my HUAWEI CAM-L21 using FastHub

[Petah]

Fair enough, although I would argue that it would be more consistent and predictable to use names like

\Zubr\array_sort()
\Zubr\array_sort_key()
\Zubr\string_replace()
\Zubr\string_contains()

vs

\Zubr\sort()
\Zubr\ksort()
\Zubr\str_replace()
\Zubr\str_pos() !== false

[nkkollaw]

Well, sure—it might be prettier, but if you know that the function is \strpos, you know that in Zubr it's gonna be \Zubr\str_pos, so you don't have to think about it.

If you deviate from really simple rules you'll start wondering if it's \Zubr\str_pos, \Zubr\string_pos, \Zubr\string_position, or \Zubr\str_position.

There will be aliases, but they will be used very sparingly.

[Petah]

But isnt the point that people (especially people new to PHP) don't know the correct function name or parameter order?

[nkkollaw]

Not really. Everyone knows it's str pos and str replace, it's just that you have to think about it and pisses you off that str pos is strpos and str replace is str_replace.

We're just trying to take some of the pain away, not trying to help out newcomers (whom—if they don't remember PHP's function names—won't remember Zubr's any easier).

Closing this as the purpose and guidelines for the project are in the README.

[Petah]

There seems to be mixed messages here. The read me says that aliasing htmlentities to html_entity_encode is ok, but you say that the above is not.