Wedge

A hundred bytes to a file that's already hundreds of thousands of bytes. Not even a 1% increase.No, it's not the same here.

When you have a class, it is simply good practice to put that stuff in, even if it is how PHP will 'interpret' it. Partly because PHP might randomly decide to make protected the default in the future, partly because other people reading the code will understand later (be that us or someone else)

Size matters. Hence my $user_info rewrite, among other things...

PHP won't make protected the default, if anything to keep it backward compatible with older scripts.
So, yeah... To me, it's the same thing. PHP regularly adds new optional parameters to their functions. You don't need to specify these parameters, they're only there if you want to change them. So, when it comes to objects, it's the same to me: the simpler, the better. If you need to change a function's scope, you can. Otherwise, you don't have to...

This is the thing... it's solely the way it is because of older scripts. There's been an argument ever since PHP 5 introduced it that it should have made scoping mandatory, and in fact prior to PHP 5.1, it would have actually tripped a E_STRICT warning.

I get the whole size thing, but quite honestly, there are other things that are as important as keeping it minimalistic, like keeping it readable. Besides, I still want to make phpDocumentor documentation and it will not like the lack of explicit scoping directives.

I can see that I won't be able to convince you and you'll have a very hard time convincing me... We'll have to agree to disagree, which I'm not a big fan of... :-/

Then again, I don't understand why you're not bothered by the tons of missing 'public' keywords in our existing methods.

Because I haven't gone through those the way I did with this one. Partly because I always use WeCSS was always subject to massive changes, and I figured I'd only worry about keeping the code actually consistent with itself once major and rapid code iteration was done. And the fact that I don't think I've ever made a single change to WeCSS at any time...

I'm not a fan of agreeing to disagree either, though I'm less a fan of inconsistent code.

The we object is actually not finished at all... And it shows ;) I'd already made a few more changes to it even before you committed your changes... Thankfully, no conflicts. But still, I was heading towards something else. I guess it always feels strange having someone tell you how to code when you're right in the middle of it... I have my pride, as you know :lol:

I too am obsessional (is that even an English word?) about consistency. And because I'm also obsessional about keeping code as tight as possible (as long as it doesn't impair readability), in this case it was bound to clash with your obsession about documented code ;)

I'm not trying to dictate how code goes, as such, just that I like code cleanliness, and to me code that clearly indicates its scope is more clean than relying on PHP's rather idiosyncratic approach. There's an excellent article about how messed up PHP is in that respect, so anything we can do to make it make sense is better.

Well, for starters, I just removed all occurrences of PREG_PATTERN_ORDER in the code. Cleaner.
I'm still of the opinion that we should rely on PHP's default behavior, because there has never been a case, AFAIK, where they changed it without ensuring that legacy code would still work. That's even the reason why explode() accepts parameter in two orders, although they recommend the use of explode($string, $array) for consistency with implode(). But still, the argument that "PHP may change its default behavior" doesn't really stand, if you'll allow me.
Then it just comes to ensuring that users are not confused with the code. Which is also a moot reason for me: I've always pictured object methods as being public, not 'by default' but simply because I didn't even know there were methods to conceal methods... I know, I know, PHP 4 vs 5, blah blah. Anyway, 'private' and 'protected' are keywords that are only going to mean something to very serious developers, and even they will know that the default is 'public'.
So, basically... I'd really, really like to keep code as short as possible. KISS, basically.

Or maybe the lack of alcohol will make you oppose this even more, I don't know... :^^;:

AFAIK PHP is the only language which keeps the default visibility scope to public only for the sake of compatibility with PHP4 type objects. So it becomes more unreadable if you're juggling between various languages, plus it's just good practice to have the visibility mode defined, and I'm fairly sure PHP will parse the lack of visibility scope slower even if it's less code.

Part of the issue with it is that pretty much everything in our objects is public anyway, there's very little that's protected or private - if there were more objects with visibility clauses, it would be more natural to have explicit declarations of public.

Dragooon, can you give me examples of languages similar to PHP that use a private or protected visibility by default...?

Pete, do you mean you're actually agreeing that the public keyword tends to mess things up in Wedge? :P Or did you actually mean that we should review all objects and dedicate ourselves and our days and nights in preventing plugins from accessing most of their variables and methods? :niark:

How about C++? Java? Pretty much any C-like language with OO is (and requires) explicit-declaration of scope. It's purely laziness in the half-assed approach PHP had to implementing OO originally. The only other C-like language that doesn't have explicit declaration of OO scope is JavaScript and that's even more insane to debug.

And no, I'm not agreeing with that at all :P It's simply that because most things are public, it doesn't 'matter' that stuff isn't declared.

Private methods are not about 'preventing others from accessing their methods and properties', at least not as the end in itself. The point of declaring public/private/protected, is that you get to enforce certain behaviours as well as logical separation.

For example, in the zip class I've been working on, there is a bunch of private methods. They're private because there is absolutely no reason to call them from outside the class, they are specific to that class. The only variation would be if I were to make classes that depend on that class, where protected might be better.

The idea is that you get to contain behaviour inside a given class. A better example might be the wedit component and subclassing it to implement a different editor (not currently possible, but trivial enough to make possible since it's geared up for it). Some of the stuff in there would be public - the functions called from outside the component, e.g. creating, outputting the editor and buttons. Meanwhile, some stuff you wouldn't change or allow to be changed (preparsecode comes to mind), and some stuff you wouldn't want to expose into the subclasses because they don't apply (some of the tag fixing stuff comes to mind)

And it never bothered me...
See, a web dev is more likely to use JS and PHP exclusively in their daily work. I don't see it as a problem that visibility is no concern to them...
Heck, even the system object has static variables but doesn't explicitly describe them as public... I'm surprised you didn't change them or something :PSorry, but that doesn't touch me... I'm no genius coder, but I know one thing for sure -- as long as my code is readable, it doesn't matter what logic is behind it. One logic is enough, mine doesn't encompass 'separation' or 'behavior'. :-/Just look at wetem, once again... About half of the methods are private. I clearly separated private methods from methods that I want to expose. I 'got' the logic as you define it. I just didn't see any reason to add a 'public' keyword when not needed. And you didn't bother to add it, either, AFAIK... ;)

I'm just... Well I'm just sayin', I like consistency in our code. I'm okay with our 'areas of interest' using two slightly different ways of coding (yours and mine), I'm less okay with the 'no man's land' being less tightly maintained, and even less okay with having my areas of interest adopt different rules (e.g. public vs no keyword) under my own rule ;)
It's not a matter of whether or not it's "my" code, it's just that when it's code I tend to modify a lot, there are things I like to do my way, and having public keywords just isn't something that I usually do.

And once again, I left wetem alone knowing full well it was going to change over time - and be subject to big changes. Once it's settled down, we can go through and clean it up should we decide it is necessary. Little point changing it if it's going to change again.

Remember, the code isn't just for you to read.