On May 25, 2010, at 4:44 AM, Ford, Mike wrote:
>> -Original Message-
>> From: Philip Olson [mailto:phi...@roshambo.org]
>> Sent: 19 May 2010 05:44
>> To: PHP Documentation ML
>
>
>> Two new entities being proposed:
>> - version.trunk.after.53
>> "This is in Subversion trunk only, and
> -Original Message-
> From: Philip Olson [mailto:phi...@roshambo.org]
> Sent: 19 May 2010 05:44
> To: PHP Documentation ML
> Two new entities being proposed:
> - version.trunk.after.53
>"This is in Subversion trunk only, and will probably exist as of
> PHP 5.4 or 6.0."
Brilliant id
On Wed, May 19, 2010 at 06:44, Philip Olson wrote:
> Two new entities being proposed:
> - version.trunk.after.53
> "This is in Subversion trunk only, and will probably exist as of PHP 5.4 or
> 6.0."
> - version.trunk.changelog
> "Future"
Do we need both?
The changelogs only list the versi
On 05/19/2010 06:45 AM, Daniel Convissor wrote:
Hi Philip:
Nobody knows if/when PHP 5.4 or PHP 6 will exist, yet commits are happening in
php-src/ trunk. We need to figure out how to document this stuff in such a way
that we:
...
Here's a proposal that may work, please critique:
Looks g
Hi Philip:
> Nobody knows if/when PHP 5.4 or PHP 6 will exist, yet commits are happening
> in php-src/ trunk. We need to figure out how to document this stuff in such a
> way that we:
...
> Here's a proposal that may work, please critique:
Looks good. Thanks for thinking about this stuff.
--D
Hi Hannes,
Thank you for your quickly response!
Actually, the proposal made by Jesus Cova is focused as you say, like a PHP
user group, and I think he is reffering to have a stand alone infrastructure
to run the website, the webhosting and domain by appart.
Anyway Hannes, thank you for the start
You guys don't need PHP.net approval for this.
Anyone can create a user group or portals around and for PHP, so by
all means; go for it!
If however you are asking if the infrastructure and systems should be
hosted by php.net.. then things get complicated and I don't know what
to say.
-Hannes
On
Hello everyone,
I am agree with Jesus Cova's proposal, to launch a website or portal in
spanish. What do you think if we (the hispanic and spanish contributors) can
get informed, up to dated, to all the hispanic talking community regarding
to activities, our own forums, official PHP news and its d
On 22.07.2007 03:38, Philip Olson wrote:
If there are concerns or other suggestions for doing this then please
express them now. I'd like to finish this up before the end of the
month.
I don't think anybody sane would object =)
The docs should be up to date, it's no museum after all.
--
Wbr
Hi Jakub,
Jakub Vrana wrote:
Poll results:
[...]
Thank you for the opinions, I've added void to Pseudo-types.
Thanks for adding ;-)
Friedhelm
Poll results:
Null return type instead of void:
+2 jakub, richard: true return type
-3 tony, derick, friedhelm: isn't so explicit as void
+0 etienne: differentiate between really void in echo and null in other
functions
-3 dave, hartmut, friedhelm, nuno: add void to Pseudo-types instead
Remove v
Hartmut Holzgraefe wrote:
> () has different meanings depending on which language you look at,
> in C++ () is like (void) while in C it is like (...), so lets
> stick with the explicit (void) to avoid misunderstandings
BTW Livedocs use () instead of (void).
Jakub Vrana
Jakub Vrana wrote:
Hello!
Would you agree with removal of the word "void" in methodsynpsis both
from return type and parameters list?
I propose to change the return type to "null" which it really is and
remove it completely from parameters list as it is the way to declare
that function doesn't
Friedhelm Betz wrote:
Dave Barr wrote:
Can't we add "void" to http://php.net/language.pseudo-types instead?
+1 from me
another +1
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
Dave Barr wrote:
Jakub Vrana wrote:
Hello!
Would you agree with removal of the word "void" in methodsynpsis both
from return type and parameters list?
I propose to change the return type to "null" which it really is and
remove it completely from parameters list as it is the way to declare
tha
Jakub Vrana wrote:
Hello!
Would you agree with removal of the word "void" in methodsynpsis both
from return type and parameters list?
I propose to change the return type to "null" which it really is and
remove it completely from parameters list as it is the way to declare
that function doesn't
Sean Coates wrote:
> Oliver Block wrote:
>
>>I don't know, if you discussed on that lately/in the past but wouldn't it be
>>a
>>good idea, if pages that give an overview over the functions of an extension
>>would be sorted differently?
>
> I like the output, but this listing is currently gener
Oliver Block wrote:
> I don't know, if you discussed on that lately/in the past but wouldn't it be
> a
> good idea, if pages that give an overview over the functions of an extension
> would be sorted differently?
I like the output, but this listing is currently generated by scripts,
so in order
I don't know who invented proposal system, but I dislike it.
Proposals votings and so-called "democratic system" is evil. If we
can't find a consensus then we are very bad team. I personally enjoy
solving phpdoc tasks and act on my own, but programming proposal for
my chaotic nature is not dif
A few topics for this section:
Yes, very good list Phillip, though I'm not sure the content lends itself to
the security section. Perhaps features, perhaps tutorial?
A tutorial section would be nice, however, we dont apparantly have
any such section :)
The only thing we need to do is decide where
> > > A few topics for this section:
> >
> > Yes, very good list Phillip, though I'm not sure the content lends itself to
> > the security section. Perhaps features, perhaps tutorial?
>
> A tutorial section would be nice, however, we dont apparantly have
> any such section :)
>
> >
> > The on
* Thus wrote Aidan Lister:
> > A few topics for this section:
>
> Yes, very good list Phillip, though I'm not sure the content lends itself to
> the security section. Perhaps features, perhaps tutorial?
A tutorial section would be nice, however, we dont apparantly have
any such section :)
>
>
> A few topics for this section:
Yes, very good list Phillip, though I'm not sure the content lends itself to
the security section. Perhaps features, perhaps tutorial?
I've documented the "official" way to disable it, now. See
http://au.php.net/manual/en/function.get-magic-quotes-gpc.php
http://l
On Monday 30 August 2004 09:46, Aidan Lister wrote:
> "Derick Rethans" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > On Sun, 29 Aug 2004, Gabor Hojtsy wrote:
> > > > I think we need to create a section in the manual, similar to
>
> "References
>
> > > > Explained" with all the
"Derick Rethans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Sun, 29 Aug 2004, Gabor Hojtsy wrote:
>
> > > I think we need to create a section in the manual, similar to
"References
> > > Explained" with all the information about magic quotes.
> > >
> > > What do you think?
> >
On Sun, 29 Aug 2004, Gabor Hojtsy wrote:
> > I think we need to create a section in the manual, similar to "References
> > Explained" with all the information about magic quotes.
> >
> > What do you think?
>
> Would be nice. Three of the cornerstones are: register_globals,
> references and magic_q
I think we need to create a section in the manual, similar to "References
Explained" with all the information about magic quotes.
What do you think?
Would be nice. Three of the cornerstones are: register_globals,
references and magic_quotes :)
Goba
On August 18, 2004 03:52 pm, Gabor Hojtsy wrote:
> >>We may need a livedocs person to tackle this as the structure is already
> >>in place. Using the same example we have the following in the
> >>methodsynopsis (split from one line to fit in this email):
> >>
> >>
> >> intwidth
> >>
> >
> >
We may need a livedocs person to tackle this as the structure is already
in place. Using the same example we have the following in the
methodsynopsis (split from one line to fit in this email):
intwidth
I added a patch to do this.
http://www.powertrip.co.za/livedocs/
Please notice Ilia
* Thus wrote Philip Olson:
>
> > >> integer > >> choice="opt">width
> > >>
> > >> VS
> > >>
> > >> width
> > >
> > > Parameter has no type attribute, so only the former is possible.
> >
> > Ups, parameter also has no choice attribute, it is of paramdef. Which in
> > turn can only be added
> >> integer >> choice="opt">width
> >>
> >> VS
> >>
> >> width
> >
> > Parameter has no type attribute, so only the former is possible.
>
> Ups, parameter also has no choice attribute, it is of paramdef. Which in
> turn can only be added inside a funcprototype according to the DocBook
>
width
But anyway Goba what tags (if any) do you suggest for this?
This last option seems to be fine with me.
Should go as far as adding the type here too?
integer width
VS
width
Parameter has no type attribute, so only the former is possible.
Ups, parameter also has no choice attribute, it is
width
But anyway Goba what tags (if any) do you suggest for this?
This last option seems to be fine with me.
Should go as far as adding the type here too?
integer width
VS
width
Parameter has no type attribute, so only the former is possible.
Goba
> > http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail
> >
> > As far as rendering, right now & and [] are typed into the parameter
> > listing and this feels dirty. If we could use a role with the parameter
> > tag (Curt suggested this in irc) it might solve this. For example:
Done. But if this information is shown it seems we'd also have to
include all parameter information, like if it's optional. Look again
at the exif_thumbnail() docs for how this might look:
http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail
As far as rendering, right now & and [
> >>Type information and by reference passing should be included IMHO too.
> >>BTW the names of the parameters are missing from
> >>
> >> http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail
> >
> > Livedocs does not handle parameters with & correctly, they show
> > up blank. I'l
Type information and by reference passing should be included IMHO too.
BTW the names of the parameters are missing from
http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail
Livedocs does not handle parameters with & correctly, they show
up blank. I'll clean exif up, and add the typ
> > (ii) Parameter List: I'd like to see this kept as compact as
> > possible, so I'd prefer to do without the vertical spacing
> > between the parameter name and its description. (Also, if it
> > were possible to merge the top and bottom dashed borders, that
> > would be great!)
* Thus wrote Gabor Hojtsy:
>
> BTW the names of the parameters are missing from
>
> http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail
livedocs doesnt seem to like:
&width
And is very picky with whitespace between as well.
Curt
--
First, let me assure you that this is no
(ii) Parameter List: I'd like to see this kept as compact as
possible, so I'd prefer to do without the vertical spacing
between the parameter name and its description. (Also, if it
were possible to merge the top and bottom dashed borders, that
would be great!) However, I would lik
Philip Olson wrote:
I thought about this but here's why I went with one description.
First, the short definition (purpose) is already in the refpurpose
of the function. Also, writing a summary for each would be a bit
too difficult. As far as using just the first para, I think it'd
be confusing ha
> >> I thought about this but here's why I went with one description.
> >> First, the short definition (purpose) is already in the refpurpose
> >> of the function. Also, writing a summary for each would be a bit
> >> too difficult. As far as using just the first para, I think it'd
> >> be confusi
Gabor Hojtsy wrote:
I thought about this but here's why I went with one description.
First, the short definition (purpose) is already in the refpurpose
of the function. Also, writing a summary for each would be a bit
too difficult. As far as using just the first para, I think it'd
be confusing ha
I thought about this but here's why I went with one description.
First, the short definition (purpose) is already in the refpurpose
of the function. Also, writing a summary for each would be a bit
too difficult. As far as using just the first para, I think it'd
be confusing having it so far apart
> > Oh, I like these! I have a few comments that I'd like to cast into
> > the pool for discussion:
> >
> > (i) Personally, I'd like to see the Parameter Information and Change
> > Log before the full description, so I'd go for something like:
> >
> > Definition(proto + *short* descr
On Wed, 11 Aug 2004, Ford, Mike [LSS] wrote:
> Oh, I like these! I have a few comments that I'd like to cast into
> the pool for discussion:
>
> (i) Personally, I'd like to see the Parameter Information and Change
> Log before the full description, so I'd go for something like:
On 10 August 2004 23:53, Philip Olson wrote:
> > I'll work on some examples, this is going to be good.
>
> Here's an example where:
>
> * Two new sections: Parameter listing and CHANGELOG
> * The parameter listing is a variablelist
> * The CHANGELOG is a table
>
> http://livedocs.phpp.o
> I'll work on some examples, this is going to be good.
Here's an example where:
* Two new sections: Parameter listing and CHANGELOG
* The parameter listing is a variablelist
* The CHANGELOG is a table
http://livedocs.phpp.org/index.php?l=en&q=function.exif-thumbnail
This looks pretty
If you expect a table layout, why overload simple paragraphs with
attributes? If it is going to be a table, then para is not right for the
markup IMHO. It does not fit semantically and does not fit into DocBook
either. BTW I have not checked, but I don't think docbook has a version
attribute wh
> > The above would output something similar to:
> >
> > CHANGELOG
> >
> > ---
> > |Version | Role | Description |
> > ---
> > |4.3.0| |foo() is binary sa
Okay this sounds good, let's do it! The following would go right
along with our new refsect1 style, does it appear doable?
&reftitle.changelog;
foo() is binary safe.
The length parameter is optional with a default value of 1024.
length
The above would output something simil
> >
> >
> > length
> > 4.2.0
> >
> >Became optional with a default value of 1024.
> >
> >
> > ...
> >
> >
> > Maybe it's not generic enough, could we cover every condition?
> > , , etc. Thoughts?
>
> As the TODO suggests we planned to introduce roles, and not new tags. In
>
What it will contain:
1) Parameter changes (new, modified, ...)
2) Function changes (new features, new behaviors, ...)
3) PHP Version info for each change
From TODO:
new roles: seealso, newparameter, and changedparameter.
That idea is similar and here's one of the threads on the topic:
http://m
Now as to the CHANGELOG, I am guessing nobody will implement it
in DSSSL (I know I won't) so focusing on livedocs may end up
happening. Livedocs or bust, 2004!
Or 2005, 2006, 2007,. I don't mind focusing on livedocs, because I have
some free time now. But I would like to have the oficial websi
> > > This would be great and it's a perfect time to implement because
> > > when people update old docs to the new refsect1 style we would
> > > also implement these changelog entries! Woohoo!!!
> >
> > What is the new refsext1 style? The credits tag?...
>
> Each manual page is split up in sectio
> > A partial proposal: CHANGELOG refsect1
> >
> > What it will contain:
> > 1) Parameter changes (new, modified, ...)
> > 2) Function changes (new features, new behaviors, ...)
> > 3) PHP Version info for each change
> >
> > From TODO:
> > new roles: seealso, newparameter, and changedparameter.
> A partial proposal: CHANGELOG refsect1
>
> What it will contain:
> 1) Parameter changes (new, modified, ...)
> 2) Function changes (new features, new behaviors, ...)
> 3) PHP Version info for each change
>
> From TODO:
> new roles: seealso, newparameter, and changedparameter.
Of course this is
I like the theory, its always handy to tell what has changed between version x
and version y. The implementation on the other hand, will be a bit more
interesting i think.
Nathan.
On Wednesday 28 July 2004 12:25, Philip Olson wrote:
> A partial proposal: CHANGELOG refsect1
>
> What it will cont
> Gabor: obviously I could change it and then build it locally, but what i
am
> trying to ask is how that would affect www.php.net - where I wanted to
replace
> the current definition. :)
>
> It may be that i am not making any sense, or not understanding you, for
which
> i apologise, and we can tr
> > The language it was written in is DSSSL, a LISP dialect. I was unable to
> > understand most of it :((
>
> well, for me it still works better than the other LISP dialect that
> doesn't even look like LISP (XSLT) ;)
XSLT is at least readable for me. Maybe I'll get into some
more DSSSL, as I w
hmm, I am sure there must be some way of learning / getting into it. :)
James
> -Original Message-
> From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 08, 2002 10:39 AM
> To: Gabor Hojtsy
> Cc: James Cox; phpdoc
> Subject: Re:
Gabor Hojtsy wrote:
> The language it was written in is DSSSL, a LISP dialect. I was unable to
> understand most of it :((
well, for me it still works better than the other LISP dialect that
doesn't even look like LISP (XSLT) ;)
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-
Hi,
Gabor: obviously I could change it and then build it locally, but what i am trying to
ask is how that would affect www.php.net - where I wanted to replace the current
definition. :)
It may be that i am not making any sense, or not understanding you, for which i
apologise, and we can t
> Right now, we use the style as seen here :
http://www.php.net/manual/en/install.windows.php and it's really not very
clear that we are trying to highlight it as something that _must_ be read,
since it's really important. (in theory :)).
>
> I propose something much lighter (not having that ugly
> I'd love to know your position on writing a short section
> about "SQL injection and others" in security.xml, something
> similar has already done for filesystem security.
>
> It aims to be an introduction into the very basics of PHP
> related database security and vulnerability, because:
>
65 matches
Mail list logo
