Guidelines are incomplete about zubr

[nkkollaw]

Kahlan stubs on php functions works only when you test psr0 / psr4 classes - it mocks composer autoloader. So it will not work with functions
In this case, we can simply create a class with static methods instead of separate functions.

Should we move the conversation to #2 ..?

UNRELEATED: are we all in Poland? :-)
I am. Dunno about you folks :)

Wrocław here (although I'm Italian).

[ddziaduch]

Gdańsk here

[radmen]

The thing that bothers me in PHP: convention of "segments" order in a function name.

Eg. there's urldecode() and parse_url(). First one is in format: $SUBJECT$ACTION, second in: $ACTION_$SUBJECT.

If it makes sense I'd like to unify this to a common format: $SUBJECT_$ACTION(). This would result in renaming parse_url() to url_parse().

What do you think about it?

[nkkollaw]

I see what you mean, and I agree that it's not great.

I think however that we should keep function names the same, so that one doesn't have to relearn the language. What I mean is that if I know PHP's build-in function is strpos, I can expect its equivalent to be \PHP\str_pos, and for parse_url I'd expect it to be in \PHP\parse_url, not \PHP\url_parse.

My idea is to create a wrapper to PHP build-in functions that changed as little as possible, so that it can be very intuitive to use. I do think that we can use aliases, but they should probably be used as little as possible.

What do you think instead of the concept of plugin? We could have something like this, in this case a plugin called "fix-common-format" let's say, that fixed all the functions by doing:

\PHP\PHP::addAlias('url_parse', function($url) {
    return parse_url($url);
});

Then we could use magic methods to catch url_parse and call the function provided by the plugin. Just an idea but it would allow to "pick" fixes that one is interested in, and would allow adding many aliases without "polluting" regular names.

[radmen]

I think however that we should keep function names the same, so that one doesn't have to relearn the language. What I mean is that if I know PHP's build-in function is strpos, I can expect its equivalent to be \PHP\str_pos, and for parse_url I'd expect it to be in \PHP\parse_url, not \PHP\url_parse.

Good catch. It makes sense to keep the naming as you suggest.

What do you think instead of the concept of plugin? We could have something like this, in this case a plugin called "fix-common-format" let's say, that fixed all the functions by doing:

I'd say that we shouldn't complicate things. If the library is meant to be a wrapper with sane functions API it should stay that way.

Plugins may be next step, but definitely not now.

[nkkollaw]

Plugins may be next step, but definitely not now.

I agree.

I think the priority is consistent naming (underscore) and argument order. We should tackle consistent error reporting as well (returning false vs. throwing exception vs. doing nothing), but perhaps in the future.

Do you have anything to add to the guidelines? I think it's us 2 so far, let's do this! :-)

[radmen]

IMO theses Guidelines are enough to start.

[nkkollaw]

OK.

I'll add some more functions today. Would you want to feel like creating a stub for tests?

[ddziaduch]

@nkkollaw I tried to add Kahlan yesterday. But Kahlan stubs on php functions works only when you test psr0 / psr4 classes - it mocks composer autoloader. So it will not work with functions :(

[nkkollaw]

@ddziaduch : that sucks, but thanks for trying.

Perhaps we can create a wrapper class, that simply calls our function(s)?

UNRELEATED: are we all in Poland? :-)

[radmen]

Kahlan stubs on php functions works only when you test psr0 / psr4 classes - it mocks composer autoloader. So it will not work with functions

In this case, we can simply create a class with static methods instead of separate functions.

UNRELEATED: are we all in Poland? :-)

I am. Dunno about you folks :)

[nkkollaw]

Closing this as we've established that guidelines in the README are enough to start.