Link: http://news.php.net/php.internals/36536
One question - are you crazy? I heared about break with goto capabilities -
that's understandable - you could break 2 or 3 level loops, but this one
shit.
PROTECTED]:
On Fri, Apr 4, 2008 at 1:17 PM, Arvids Godjuks [EMAIL PROTECTED]
wrote:
just emotions, sorry.
But why you didn't keep the break [1,2,3]; ? That was fine and
understandable and it was limited to loops, but with this will make code
messy, especially with if statements. I personally
an error in PHP 5.2.5 that function myfunc() can't
be redeclared. This would in my opinion be very useful for methods in
classes.
Greetings,
Krister Karlström, Helsinki, Finland
Arvids Godjuks wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others
, Richard Quadling [EMAIL PROTECTED]:
On 08/04/2008, Arvids Godjuks [EMAIL PROTECTED] wrote:
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases.
Especially
if named parameters are implemented.
Sometimes
I think type hint's would be good optional functionality. Those who need
will use it, others will not. I'd probably use it in some cases. Especially
if named parameters are implemented.
Sometimes what I really want is named parameter pass like
function myfunc(array $array, string $string = null,
Thouse who are asking about type hinting for function args are right. It is
logical to implement return type hinting with arg type hinting.
They should work either independantly (you can specify any on them or all
together) or if you declare return type - declare arg types too (then we
should have
Christian Schneider
We have 2 possibilities.
* Throw an error
* Make type conversion
What to select is PHP developers team prerogative.
About example - that's MySQL who is very tollerant, other databases may not
threat well things like passing an ID to numeric field as string. That's bad
style
2008/4/15, Felipe Pena [EMAIL PROTECTED]:
Em Ter, 2008-04-15 às 01:05 -0400, Sam Barrow escreveu:
If somebody does have a patch for this or is working on one let me know.
Whether this will be implemented or not I would like to assist with this
patch so I can use it for personal use at the
What about types like
array
mixed
Ok, for mixed we may not use type hinting at all - does patch allow to
hint only part of function args?
If we have a function, witch takes as 1st argument array or string and other
args should have strict types or just use call like myFunc(Array($string),
.)
Christian Schneider
I don't like the difference between
function (int) test($value) { ... }
and
function test(integer $value) { ... }
First is function return value should be int, second is function arg should
be int.
So full syntax will be like this
function (integer)
+1 for strict types.
That way it will be simple:
* Don't need - then don't use at all
* You need it - you use it fully.
One thing than left to clearfy - do we allow to hint only part of args or do
we go the road if hint args, then hint them all! (I'm personaly for second
one - be strict)
2008/4/18, Lukas Kahwe Smith [EMAIL PROTECTED]:
Hello All,
I just want to bring in a different perception on the proposed feature. I
think people are very focused on what I call library code. This is the
kind of code that should in theory be worked on less, than the glue code
that you write
2008/4/18, Sam Barrow [EMAIL PROTECTED]:
On Fri, 2008-04-18 at 10:40 -0700, Kalle Sommer Nielsen wrote:
Hey Internals
I've been wondering for quite some time why PHP doesn't allow you to
access
arrays when you assign it to a value like in Javascript:
function ArrayTest(Array $range)
2008/4/24 Wietse Venema [EMAIL PROTECTED]:
FYI,
Taint support for PHP 5.2.5 has been updated. The 20080423 version
improves support for PCRE, and fixes a harmless read-after-free bug.
The primary goal of this code is to help PHP application programmers
find and eliminate opportunities for
I'm +1 for this syntax
function int myfunction(int $param)
{
return $someint;
}
C/C++ like, easy to understand
And bad idea about making a return type function - looks very useless and
will not be used a lot. Work with objects with methods returning an object
of some kind, then you can do
Just use Unicode and don't even think about backward compability, because
thouse who need it most probably still are with PHP4 and MySQL 3.x
Most normal developers are for years with utf-8 for now and even wouldn't
notice it.
So +1 for pure Unicode. No switches. Lame hosting companies 100% will
Well, at least in my country i haven't saw any normal programmer not using
unicode :)
2008/5/5 Christian Schneider [EMAIL PROTECTED]:
Arvids Godjuks wrote:
Most normal developers are for years with utf-8 for now and even
wouldn't
notice it.
Sorry to destroy your pipe dream but that's
+1 for this. Just clean the code once and for all.
2008/5/23 Lars Strojny [EMAIL PROTECTED]:
[ forgot to sent that to the list ]
Hi Philip,
Am Dienstag, den 20.05.2008, 12:55 -0700 schrieb Philip Olson:
[...]
PHP 5.3 is approaching fast, so let's conclude our dealings with
magical
Use XCache instead - it's simple, fast and stable. APC is far more complex
and unstable (is't like code for code)
2008/5/23 Edward Z. Yang [EMAIL PROTECTED]:
I don't really care either way, but if it's a well known fact, might as
well stop trying. Does APC work on Windows? I recently submitted
IMHO, remove {} and leave [] for strings. Strings is array of chars, so []
syntax is fully OK
2008/6/14 Chris Stockton [EMAIL PROTECTED]:
I personally have always used {} for string offsets because it just felt
right. [] seems like it is for arrays, for me, using it on strings makes me
feel dirty.
Could we maybe visit some of the ideas you have had with {} syntax offering
some
2008/6/16 Edward Z. Yang [EMAIL PROTECTED]:
PHP userland code may not treat strings as first class arrays, but
that's certainly how they are represented internally.
Anyway, it would be neat if we could get that foreach syntax to work. I
get sick of for($i = 0, $c = strlen($str); $i $c;
+1 from me - unicode is very very needed indeed.
Normaly on every project I have to deal with 3 languages - english, russian
and latvian - and there is no fun in making advanced html/bbcode parser (not
based on str_replace or preg_replace - it is far more complex than that)
using mb_string
Hello.
I think this should be optimized.
I'm not an expert ofcourse, but as I understood there is only one case witch
need a special treatment - require/include _one when a file with equal
contents is included from different directories.
You can make a switch witch controls if lstat is made or
Yesterday I made some tests on my site with strace to see how much lstat I
have and how can I optimize them. Well, I managed to get rid of them almost
at all, but now I have some questions about include_path and including files
based on current dir.
I have such structire of files
/home/file/www
I think it is good as it is.
Realy, I'd prefer even a change to global like this:
function test ($someparam) global ($someGlobalVariable) {
// code here
}
Or even make it consistent with lamda's and make use of use statment
instead of global.
P.S. I know my comment will be yeald at, so
Not so lately I read an article about compacting library files into one big
file and with opcode cache it gave 22 times faster aplication load.
Article is in russian, so thouse who can read it be my guest:
http://dklab.ru/chicken/nablas/49.html
For others I will make a quick summary.
What was
Well, you can do that right now, PHP supports that for ages.
?php
$myVar = 'print';
$myVar('Hello!'); // Outputs hello
?
So lamdas realy do not change anything in this context. What they do is make
our life easier by making us able to live without create_function().
Anyway, removing $ is bad
I completely agree with jvlad's thoughts - for me namespace is ability to
separate two different libraries from each other so that they don't
conflict. I don't need namespaces just to write my own application using
them to be cool, and I probably would never use a namespace for small or
middle
2008/9/22 Stanislav Malyshev [EMAIL PROTECTED]
Hi!
3. Functions will not be allowed inside namespaces. We arrived to
conclusion that they are much more trouble than they're worth, and summarily
we would be better off without them. Most of the functionality could be
easily achieved using
Maybe just use . as namespace separator.
MyNameSpace.SomeClass::_getInstance()-SomeDBClass-Query();
That will eliminate all resolution problems, it isn't used for anything than
string concatenation, and it's one symbol. It's 100% better than \ and I
think it would be better than ::: or
concatenation here and there ;)
Regards,
Stan Vassilev
- Original Message -
From: Arvids Godjuks
To: Stan Vassilev | FM
Cc: PHP Internals List
Sent: Monday, September 29, 2008 9:19 AM
Subject: Re: [PHP-DEV] solving the namespace conflict issues
betweenfunction/staticmethod class
namespaces without any need to cut functions and constants.
2008/9/29 Richard Quadling [EMAIL PROTECTED]
2008/9/29 Arvids Godjuks [EMAIL PROTECTED]:
String concatenation woun't be affected, because you can't concatenate
class
definitions like in my example.
To concatenate you should use
2008/9/29 Jordi Boggiano [EMAIL PROTECTED]
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning [EMAIL PROTECTED] wrote:
+1, I second this completely
From someone who *was* using namespaces developing against the 5.3
branch,
this is going to happen sooner or later. I found that :: just causes
2008/9/29 jvlad [EMAIL PROTECTED]
So as prevoius speaker suggested, and I personaly got to conclusion
in
other thread that : is ideal. Short, isn't taken.
$a = $b?A:B:C:D;
Will _you_ write such code? No. Will anybody from this list write such
code?
You may want to write
$a
People, why you just don't change the namespace separator to something
except :: and sole all the problems one and for all? God damn, use : if you
need - just push it out working! Most of my fellow programmers are just sick
with reading internals discussing how to throw a feathure away because
+1 on #3 (I really was for option #2, but #3 seems to be more elegant).
As I remember this is a voting thread, but most of you started to argue
again and trashed the thread. Please stop doing that.
My vote is for option #3 and for Gregs proposal too.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2008/10/21 Stan Vassilev | FM [EMAIL PROTECTED]
Hi,
Guys, this is like junior school in here.
Let me put some things in perspective:
1) The location of backslash on foreign keyboard is entirely irrelevant for
the choice of namespace separator. Why? You already use this *every day* to
I think this should be implemented by user. If you are full OOP in your
application, then just register all your objects in some global object (In
my case I have a global singelton) and trigger hiv removal at the end of
your application. If you have destructors written in every object - they
will
This was argued for months, there was tons of emails to read and backslash
is best for most people. PHP is dynamic language - that makes some major
restrictions, so you just can't apply something that is already in use
easily. That's why :: was rejected in first place. That's why . was
rejected,
I totally agree with Josh, same argument - resolving to global resources
should be by default, so we don't need to rewrite a lot of code, witch we
want to namespace. Namespaced functions will be called far less in code then
global ones.
2008/10/28 Josh [EMAIL PROTECTED]
Hey,
I think that
People, when you will start to learn that such approach is a mess?
First, use ' ' instead of and format your SQL better and you woun't have
any problems:
?php
define ('STATUS_ACTIVE', 1);
define ('NUM_PER_PAGE', 25);
// I beleve here is a lot of code
// ...
//
$q = 'SELECT
ID, Name
Hi Timm!
Worth it? I think that's absolute necessity to add this patch, because if it
gives almost 2 times speed boost for typical frameworks, it's just fantastic
(well, the less calls, the less performance boost, but really some monsters
like Zend or CakePHP and others will definitely benefit
Did anyone look into this bug? http://bugs.php.net/bug.php?id=34515
I get this on my windows box right now. I made strace with StraceNT tool, I
posted it here:
http://paste.php.lv/685ed5f46f22a328fee5ca8fd917d70a?lang=text
It's 1.19 MB long.
You can email me personaly if needed.
Hello everyone.
I've been writing ?php echo get('something')? for some time now at the
last project and it really sucks. I understand reason on depricating
short_open_tag and I agree. But I have a proposal witch can ease templating.
Remove short open tag, but leave ?=get('blah')?. Bacicaly PHP
Hello Internals.
I'm a userland PHP developer, I readed all the proposals about type
hinting and did some code writing with type hinting to see how it
looks like. Well, to my understanding it's a mess if both types of
type hinting are done.
Here is an example of a function:
function
2010/1/19 Pierre Joye pierre@gmail.com:
On Tue, Jan 19, 2010 at 12:31 PM, Michael Wallner m...@php.net wrote:
On 01/19/2010 01:27 AM, Stanislav Malyshev wrote:
Hi!
I wrote a small patch that enables this kind of syntax in PHP:
foo()();
I'd rather see two other things that are missing,
Hello internals!
After reading the discussion for some time and thinking through what has
been written, I came to the conclusion that something like legacy namespace
witch is enabled by default is required. Why? Because some projects are big
and you usually migrate them in chunks. So that way you
Hello all!
Julien this weekend was at the conference in Riga and we talked with him
exactly about this, how it could be handled and stuff.
The bottom line of our discussion was that I expressed the opinion that
things should really start to move as of 5.5 - postponing it will not make
any
2012/11/13 Anthony Ferrara ircmax...@gmail.com
There's one important thing that I think you all are missing here. You keep
bringing up that we should just use the normal deprecation process. The
problem is that the deprecation process was never designed for a feature
like this.
Look at what
Hello internals.
Sometimes I wonder if people even read the stuff that is written here. I
understand that this thread got long, but it's not that bad - most messages
are short and readable, easy to follow.
As with APOCALYPSE WILL HAPPEN style claims, that we see here, I just
don't understand your
I have to agree with Lester.
It seems that there is a conspiracy to push annotations into PHP :D No,
really, it's like goons decided that PHP needs annotations no matter what
and just flooded the mailing list.
I think: The line must be drawn here, this far, no further! © Star Trek
Before adding
2013/1/11 Clint Priest cpri...@zerocue.com
Even so, C++ is not the only object oriented language out there.
-Clint
I could not resist the urge to suggest D as an option :) Sorry for this
troll attempt.
Well, there is Quercus out there in the wild, they did it. Sure a total
rewrite
Hello internals.
I'm actually using proctitle extension and it's very handy because we run
like 10+ daemons written in PHP that we manage. Without it we would be lost
:) But the actual awareness of the proctitle PECL extension is very low.
Also it does not work on windows.
I'm all over the idea
I also don't like the RFC proposed syntax. I have to say that I don't
really like those short magic-like syntax things in in other languages too.
If you work with them on the day-to-day basis and tools are built around
those concepts - it's one thing. In PHP syntax is mostly self-explanatory
and
Hello, didn't read the whole thread, just a few messages at the start. But
because I'm replying to the starting message, it's not relevant :)
In principle, as a user-land developer, I agree with the motion. It's too
much fancy new shiny stuff lately and no actual improvement on the old
stuff that
2013/4/10 Dmitry Stogov dmi...@zend.com
Hi,
Recently, I've found that OPcache optimizer misses a lot of abilities,
because it handles only one op_array at once. So it definitely can't
perform any inter-function optimizations (e.g. inlining).
Actually, it was not very difficult to switch to
2013/4/10 Florin Patan florinpa...@gmail.com
On Wed, Apr 10, 2013 at 4:07 PM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
2013/4/10 Dmitry Stogov dmi...@zend.com
Hi,
Recently, I've found that OPcache optimizer misses a lot of abilities,
because it handles only one op_array
2013/4/10 Zeev Suraski z...@zend.com
-Original Message-
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
Sent: Wednesday, April 10, 2013 4:08 PM
To: PHP Internals
Subject: Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?
2013/4/10 Dmitry Stogov dmi...@zend.com
2011/8/4 Lazare Inepologlou linep...@gmail.com:
Hello everyone.
I am new to the php-internals list. I have joined because I have
implemented a feature that I would like to be included in the php
language: a shorter syntax for lambdas. I am going to briefly present
it here. Apologies for the
Oh, and I forgot one more thing:
As I read the internals, I noticed many times that PHP lexer is
somewhat limited in it's capabilities and sometimes the features are
dropped because of this issue.
It can be the case that the can be ambiguous and it will be just
impossible to add at this stage.
I have mixed feelings about this proposal - from one point it's quite
neat - ability to mark circular references for the memory manager so
it can free them sounds very delicious, especially for some cases. I
had run into my own bunch of problems with memory in PHP in the past
and right now I'm
Just add a check on what format is used on read, write with the new
format. Deprecate the old format in next version after 5.4 (or drop it
at all in 6.0 or whatever the new major version will be).
Make a noise about the change (I can do that for the Russian speaking
community with ease).
It will
Hello, i should point out that it is all unicorns and rainbows for building
inernal apis and libraries. But in PHP you work with the world out there.
And that means you process GET, POST, xml, json and bunch of other data,
witch comes to you as text. Even db requests usually retirn text even with
Kris Craig
I usually just read the list, sometimes add if I have something to say and
I had voiced my opinion on typehinting before. And you know, just from the
stand of a userland developer who has 7-8 years of experience and devoting
myself to the excelence at PHP, i see this discussion about
I absolutely agree with this. The hurdle with the strict type hinting is
pictured very well. Strict is strict - either the whole codebase follows
it, or it doesn't follow it at all. If a part of the code uses it - means
all the code comunicating with that part has to use, or at least has to be
Michael Morris,
Type hinting means that we have hints when declaring function/method
signatures, example:
functiion do(int $someVal) {}
function doOther(string $str, mixed $pos = null) {}
As I remember, there was never a discussion about adding type hints
when declaring vars. The original
But what about optional weak (auto-convert) type hints? They should
make life if not easier, definitively a little richer when writing
API's and internal stuff, where some additional strictness and
warnings generated make sense.
And it definitively makes IDE's more happy and easier to generate
Aren't you people getting tired of saying that arguments like it's
not the PHP way or that does not fit the PHP paradigm are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's
to the creation of strongly typed languages that could
be executed on the PHP platform.
Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/2/28 Arvids Godjuks arvids.godj...@gmail.com
Aren't you people getting tired of saying that arguments like it's
not the PHP way or that does
It's quite hard to think of a compelling example. Usually you just
write the code and realize that Yea, a 'finally' statement would make
a lot of sense here.
I believe it's the kind of functionality that you learn to use in
time, just like __set, __get, __sleep, __wakeup. If first two are no
To: Arvids Godjuks arvids.godj...@gmail.com
Копия: Michael Morris dmgx.mich...@gmail.com, internals@lists.php.net
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers.
A string to number transformation is most-likely not without loosing
Combining different things into one big RFC is not a good idea. It's
hard to develop and test the work it it's in one big chunk.
Decomposition makes it much easier. Type hinting has to have it's own
RFC.
Besides - someone can be willing to do type hinting patch and don't
want to do the
Guys, you probably are too deep into the discussion that you haven't
noticed an elephant Zeev has put into the room. When the RFC procces was
put in place there was a rule outlined - if core devs decide to reject,
it's rejected. And as Zeev said last time core dev team decided that there
will be
Kris i have a question for you - who will implement a test patch? Previous
tries failed not because no one wanted, but because it was damn hard and
tricky. And ofcourse there was resistance against strict type hinting. Mine
included. I doubt any of the last timeinvolved will be willing to do that
Please.read my emails carefuly. What i said is last time the work has been
done, and two different patches have been developed and iterated. But
dificulties in implementation and strong resistance from the devs and
comunity got it killed. I actually had a post on our biggest russian
speaking IT
Secure code is not about the instrument, it's about how you write it.
Insecure spagetti code can be written in any language.
Alan Knowles
You should consider the fact that some E_STRICT stuff can one day
become E_WARNING or E_FATAL. For example calling a static method
dynamically - I would bet that someday this thing will be moved to be
a run-time fatal error and fix those if I make a mistake of doing
that.
Or not
I, for one, decided not to participate in the discussions any more
because they always change to something different in a few hours of
discussion. I'm surprised how people tend to complicate the feature
into something weird and ugly. I now understand why core team just
ignores some discussions.
I
Hi Simon!
2012/3/8 Simon Schick simonsimc...@googlemail.com:
Hi Arvids,
I pretty much like this idea as it's more strict. Let me say something
to the questions you pointed out here.
2012/3/7 Arvids Godjuks arvids.godj...@gmail.com:
I realize that with scalars it's not that straight forward
Type hints are meant to
filter input from external sources
Correction, it should read like this:
Type hints are _not_ meant to filter input from external sources
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2012/3/8 John Crenshaw johncrens...@priacta.com:
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
I like that. What should we do if this appears? As it's now - just
throw an Catchable fatal error and let the script blow-up? I would
go this far.
I think Catchable fatal error should
2012/3/8 John Crenshaw johncrens...@priacta.com:
From: Arvids Godjuks [mailto:arvids.godj...@gmail.com]
That's why I described the rules when type juggling comes into play.
If you send a string number, it is converted from string to number by the
type hint. If you send a string of characters
Overall good job. I would prefer it a little stricter like people already
mention, but it's a step forward definitively with witch I'm totally fine
to live with.
I should point out that returning false on param parsing failure on the
language level is one thing (not to mention it's not ok to do that in the
first place by my taste), but forcing that behavior on the user-land level
is kind'a too much.
Consider how the code will become much more complicated
What is consistent and exists on the internal language layer
not necessarily good for the user-land. I'm kind'a surprised no one
thought
of that.
As I said I can live with the throwing notices and warnings (and not
E_RECOVERABLE_ERROR as I personally wanted), but returning false even
I think that the null issue is not an issue. Strictly speaking if you
want null or an int - leave out the type hint and use generic argument that
will accept anything.
I think it's over-engineering to try and push a special treatment for the
null. If function/method argument accepts anything but a
2012/3/12 Lazare Inepologlou linep...@gmail.com
I'm not sure about you, but I don't wanna see that kind of thing
eventually making it's way into the language
Me neither. All I am saying is that, since int|null is already here from
the back door, I think it should be properly supported.
8 апреля 2012 г. 8:16 пользователь Yasuo Ohgaki yohg...@ohgaki.netнаписал:
2012/4/8 Ángel González keis...@gmail.com:
On 07/04/12 22:48, Yasuo Ohgaki wrote:
Hi,
The only valid reason for removing ?php from PHP script would be
security.
Since the null byte detection for fopen,
, but it's a serious proposal
for people who persist better security. IMHO.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Sun, Apr 8, 2012 at 5:34 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi,
2012/4/9 Arvids Godjuks arvids.godj...@gmail.com:
8 апреля 2012 г. 8:16
Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much
I posted the bellow text in other thread, but i should have it post here,
so i'm reposting it to this thread.
Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file concatination
to speed up file loading.
Yii framework
What happened with the proposal/RFC for expanding include/require with
additional optional second param to allow for developers to define in place
if he want's a pure PHP file to be included or a template file with direct
HTML output?
I like that proposal and take it over any other, because it
16 апреля 2012 г. 2:52 пользователь Kris Craig kris.cr...@gmail.comнаписал:
On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks
arvids.godj...@gmail.comwrote:
I posted the bellow text in other thread, but i should have it post here,
so i'm reposting it to this thread.
Well, it's time for me
related stuff.
16 апреля 2012 г. 11:09 пользователь Kris Craig kris.cr...@gmail.comнаписал:
On Mon, Apr 16, 2012 at 12:57 AM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
16 апреля 2012 г. 2:52 пользователь Kris Craig kris.cr...@gmail.comнаписал:
On Sun, Apr 15, 2012 at 2:30 PM, Arvids
16 апреля 2012 г. 11:24 пользователь Ferenc Kovacs tyr...@gmail.comнаписал:
On Mon, Apr 16, 2012 at 9:46 AM, Arvids Godjuks
arvids.godj...@gmail.comwrote:
What happened with the proposal/RFC for expanding include/require with
additional optional second param to allow for developers
16 апреля 2012 г. 16:09 пользователь Tom Boutell t...@punkave.com написал:
These tools already strip ?php tags, they would need minimal changes to
support rolling in a .phpp file unmodified. Unless I am missing something?
Sent from my iPhone
On Apr 15, 2012, at 5:30 PM, Arvids Godjuks
16 апреля 2012 г. 11:05 пользователь Kris Craig kris.cr...@gmail.comнаписал:
Arvids,
On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks arvids.godj...@gmail.com
wrote:
What happened with the proposal/RFC for expanding include/require with
additional optional second param to allow
16 апреля 2012 г. 22:02 пользователь Kris Craig kris.cr...@gmail.comнаписал:
On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer vch...@developersdesk.com
wrote:
On 4/16/2012 3:31 AM, Arvids Godjuks wrote:
That's sad really, to be honest.
I wonder if people even use this:
echo include
1 - 100 of 301 matches
Mail list logo
