On Sat, Mar 5, 2022 at 14:26, Kris Craig wrote:
Specifically, I would direct this question to
Pierre and Viktor: Do you believe that "Arrest Dictator Putin" is
appropriate for the PHP homepage?
As a Russian who fled his country because of arising concerns over Mr.
Putin's regime, I find any
Exactly. What context are we not understanding? Condemn war. Peace is
the only side PHP is about to take, it is ALWAYS good to be for peace
and against war. Is this going to separate the PHP community in any
way? No. Just - NO. Easy as that.
On Fri, Mar 4, 2022 at 09:25, Lynn wrote:
On Fri, M
Even a simple sign of solidarity against the war is important, if this
is something community can agree to, without having to fall into mutual
hatred.
I personally would love to see a clear support for Ukraine, but if that
will be causing endless debate I would give up on this in favor of a
g
insanity, is welcome, IMO.
On Wed, Mar 2, 2022 at 17:33, Victor Bolshov
wrote:
This is going to cause debate, I was sure about it. And if the
community agrees at least to state "NO WAR", that is already
something.
To provide more context on Putin's propaganda: he has bee
This is going to cause debate, I was sure about it. And if the
community agrees at least to state "NO WAR", that is already something.
To provide more context on Putin's propaganda: he has been consistently
putting more and more restrictions on nearly each and every independent
media. I can on
Hello internals.
In these dark days for humanity, we as people of civilization, people
of sanity, kind and caring people with children and families - we have
to speak up, loud and clear, in support for Ukraine. To stop Russian
aggression.
I suggest to add Ukranian flag and a supportive anti-
would effectively do nothing. I personally would be against this change
at all then.
Many thanks to the PHP team from userland, also for letting anyone
voice their thoughts and concerns on important matters!
Regards,
Victor Bolshov,
Software developer
On za, nov 13, 2021 at 08:26, Peter
IMO this feature would contradict with the Single Responsibility Principle.
Type hints are for type hinting, not for value hinting. Cheers.
Sent from Mailspring
(https://link.getmailspring.com/link/4d67851f-de69-45d9-9db1-54b16845e...@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%
Hi internals,
I think it's just as good to write:
if ($condition) return $retval;
Yes, there are subtle semantic differences the new syntax would emphasize, but
it doesn't feel like it justifies it. New syntax also means the need to support
it, for IDEs and other tools, static analysis tools, co
+1 - think everybody'd want their functions to be searchable and searching
for complex patterns like "(function)|(\|\=\>)" would really be a headache.
Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic?
2011/8/4 Antony Dovgal
> On 08/04/2011 04:39 PM, Lazare Inepologlou
Personally, I believed that traits are a *compile time injection* to a
class, so that at runtime a class behaves completely as it would if trait
methods were implemented directly in the class. That said, everything like
trait requirements for a certain interface, should be done at compile time
and
-- Пересланное сообщение --
От кого: Victor Bolshov
Дата: 23 сентября 2010 г. 8:48
Тема: Re: [PHP-DEV] deprecation status of $str{42} versus $str[42],
revisited
Кому: Chris Stockton
Personally, I use the syntax $str{1} since long time before 2006, and when
it comes to that, I
> If there were
> only two options left on earth, strict typing and strict+auto-conversion,
> I'd vote for going with just strict.
Completely agree. I'm against strict approach, but I would prefer
strict to "strict+auto-conversion".
I see a sense in weak typehints. I see a lesser sense in strict.
+1. Strict typing will only prevent PHP from being itself, while not
providing the advantages of a real statically types language (as Stas
Malyshev has mentioned in another thread of discussion).
2010/8/11 Arvids Godjuks :
> Completly agree with Zeev, most russian comunity is for the weak type
> h
Having two similar syntaxes that work differently - would make the
situation even worse that it is now - I beleive. And I totally agree
with Rasmus - strict typed language mustnt be called PHP. (Just a poor
user's notice to all of you internals' geeks out there)
2010/8/11 Stas Malyshev :
> Hi!
>
>
Yes, sorry. I've been working with 5.3 for pretty long time so I found the
original letter a bit strange.
2010/8/3 Ferenc Kovacs
> 2010/8/3 Victor Bolshov :
> > Shijiang, did you notice the
> >
> > --
> > Warning: The magic method __call() must have public visib
Shijiang, did you notice the
--
Warning: The magic method __call() must have public visibility and cannot be
static in Command line code on line 1
--
???
2010/8/3 Shijiang
> Hi,
>
> In the following sample code, I expected that the magic method __call only
> works within the class Test.
> But
+1 for "one could use the full qualified name to refer to the class name".
Making the developer care about the case of characters in one special case -
that's the sort of changes that lead to chaos. Remember that type conversion
works in a case-insensitive manner and so does most of the language
c
As man from userland, I totally agree with Larry. I see completely no sense
in raising error when a safe conversion can be done. And I don't like
current implementation at all. It is completely not-php-way.
2010/5/28 Larry Garfield
> On Friday 28 May 2010 01:54:55 am Zeev Suraski wrote:
> > At 0
+1 vote for weak typing.
I myself often (but not always) do take care about types, so for me
personally strict typing won't hurt that much. However, I beleive this will
be an overcomplicated aspect to many. As we know, there are tons of
webmasters who dont know any programming language in deep - b
Toorion, I suggest *not* your code becomes unreadable because of PHP
limitations but because of you application architecture limitations.
I see from your example that you're building a Ext.JS datagrid. And,
what is done in the example, is writing in PHP what should be written
in JavaScript. ExtJS
>From the user point of view it might seem that 5.x "string" and 6.x
"unicode" are all strings, whatever you call them. Still, I am sure
there _is_ a background for the decision to distinguish between
"string" and "unicode".
2 марта 2010 г. 1:27 пользователь Antony Dovgal написал:
> On 03/01/2010
> And I'm not sure who would actually use 'a.b' and then expect 'a_b',
> but I have to assume somebody has done that, perhaps consuming an API
> from somewhere else.
OpedID protocol uses dots in query string arguments. The
implementations could be broken by the patch.
While the "keep arguments as
I vote for (A). bind() and bindTo() seem messy to me. However, I
mostly vote for no implicit $this changes in closures (no
javascript-like behaviour), so (A+) approach would be much better than
(C) or (D). (0) case is not my choice, because I really would like to
see $this support in closures back.
Hi
> so you can with $foo->$bar() or $foo()
You're talking about variable functions/methods. But that is not the
subject of discussion. Variable functions/methods are useful but
introduce mess. This is well-known and this feature exists in PHP for
a long time - so everybody should be condidered a
x27;)
));
}
Of course, this is a special case - but I could easily imagine
ActiveRecord class in which validation is based on a similar approach.
This is why $this in closures would be useful for me - however I
definitely would like $this not to change ever.
2009/11/19 Jelrik van Hal :
> Vict
Hi.
Personally, I beleive that (A) approach is the best: "bind $this to
the object scope at creation" and never change it, issue error when
$this is used where not available. It also seems to me like this way
it could be implemented with better performance, am I right?
Dynamically changing $this
That's a completely useless discussion, isn't it? Whoever is "right"
with his opinion regarding scoping - nobody will (and nobody would
like to) change PHP's scoping for those reasons as it would break too
much existing code.
2009/11/16 Mathieu Suen :
> Etienne Kneuss a écrit :
>>
>> Hello,
>>
>>
Personally, I don't get deep into how PHP works inside, I'm just a
PHP-programmer (the man from userland). For me it will surely be
better to use 'insteadof', not 'instead'. And It seems to me more
natural to use the following syntax when using grafts:
class Foo {
use MyGraft {
public graftedCl
29 matches
Mail list logo
