Re: [PHP] Function size
On 23 May 2012, at 15:14, Tedd Sperling wrote: Hi gang: On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote: A rule of thumb is no more than 50 lines per function, most much less. Back in the day when we didn't have nifty gui screens and an 24 line terminals (yay green on black!), if a function exceeded one printed page, it was deemed too long and marked for refactoring. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. I know from the last several decades of programming, my functions have increased in number of lines. But, they have reached a limit that limit is generally about the number of lines I can read in half of my monitor's height. This of course, is dependent on monitor resolution, font-size, and how far I am sitting from the monitor. But I think this is a natural and physical limit that we don't normally recognize. I can cite studies that support my theory. It would be an interesting survey to ask programmers to review their code and provide the average number of lines in their functions AND how many lines of code their monitor's can display. In other words, look at your editor; count the number of lines your monitor can display; estimate the number of lines in your average function; and report the findings. For example, mine is about half -- my monitor can display 55 lines of code and my average function is around 25 lines. YMMV. Interesting, yes? It's a theory, yes, and for many people it may be valid, but it's not for me. The resolution of your screen; the size of your font; the colour scheme you use. These should not be a factor in the way you write your code. If they are then you'll be making decisions for all the wrong reasons. The art of software development is in taking a problem, breaking it up in to bite-size chunks, and putting those chunks together to form a practical solution. Anyone who considers themselves a better programmer because their functions are large due to their ability to handle large functions needs to keep their ego in check. Mental capacity has nothing to do with it. My philosophy for functions is simple... a function does one well-defined, discrete task, and it does it well. The inputs are clearly specified, and the potential outputs/exceptions are fully understood. Sound familiar? These requirements make it incredibly easy to write unit tests for the code. The number of times a function is used does not enter my field of interest. It's irrelevant, as is the number of lines in each function. Following this philosophy does naturally lead to fairly small functions, but as you move up the levels of abstraction they tend to grow larger. For PHP, I consider code in a file that's not within a function to be a function in itself, and the same philosophy applies. I wasn't going to respond to this thread because I think it's a largely ridiculous topic, but some of the responses have scared me. Sir Cummings (hopefully) sarcastic response about using a 5px font size demonstrated how daft it is to base function size on how much code you can see on the screen at once. Looking at the stats for your code is meaningless, and it's particularly meaningless if you're looking at lines rather than statements, but even then it lacks sufficient meaning to be worthwhile. Shiplu posted a great video on using polymorphism to properly model different behaviours of a base type, and that's great, but for PHP you need to factory in the sizeable speed difference between using a switch statement and using objects. You should never let the elegance of a solution take priority over efficiency. Tony had some curious comments... On 29 May 2012, at 08:52, Tony Marston wrote: The only reason to take a block of code and put it into its own function is when that code is likely to be called more than once so that it conforms to the DRY principle. If it is only ever used in one place then there is no point. The DRY principle -- a great principle to observe. However, having functions that are only used once does not violate the DRY principle, in fact in some ways it makes it easier to adhere to it. Also, there is a point to pulling out code that's only used once into a separate function, it's called unit testing, and if you're not doing that then YOU are in the wrong job :) KISS is more important than DRY in my opinion, and KISS should naturally lead to DRY (in most cases). The problems I have with creating lots of small used-only-once functions is as follows: - you have to create a meaningful name for each function. Oh, dear $DEITY, the hardship. Hmm, then again, naming my functions properly will help you with your DRY goals. Hmm. Seriously tho, you've refactored that code into its own function BECAUSE it's doing a discrete task. Naming it should not be
Re: [PHP] Function size
On 29 May 2012, at 14:38, Tedd Sperling wrote: On May 29, 2012, at 7:17 AM, Stuart Dallas wrote: It's a theory, yes, and for many people it may be valid, but it's not for me. The resolution of your screen; the size of your font; the colour scheme you use. These should not be a factor in the way you write your code. If they are then you'll be making decisions for all the wrong reasons. As gifted as you are, you missed the point. I'm don't think I did, but as gifted as you are, I think you missed mine :) At no time did I say that anyone should do anything to the number of lines they write. Quite right, but you did say that your functions have grown in size as the number of lines you can fit on half your monitor height has increased. So on some level you are basing your architectural decisions on that measurement, whether consciously or not. Also, at no time did I say anything about Mental capacity. Quite right, it was Tony who brought that into it. I apologise for mixing it into my general response but I couldn't let it go unchallenged because it's trying to turn it into a pissing contest which is not good for any developer in the ecosystem. My statement was not a recommendation, nor a suggestion, but rather an observation. An observation regarding known limits of human perception and comprehension. It is a known fact that we have short term memory limits -- there have been countless studies on this -- I do not want to belabor the point further. Web promotion has rekindled and advanced this interest. Here are a few contemporary books on the subject (they are all a good read): 1. Don't make me think by Steve Krug 2. Submit Now by Andrew Clark 3. Neuro Web Design by Susan Weinschenk 4. !00 Things by Susan Weinschenk 5. Seductive Interaction Design by Stephen Anderson 6. Designing with the Mind in Mind by Jeff Johnson 7. Rocket Surgery Made Easy by Steve Krug (this is not as important as above, but should be considered LAST) The earliest study I have been able to find on human perception and comprehension limits is: http://symboldomains.com/sperling.html (his study is there) George Sperling laid the basic foundation for this span of apprehension (as he called it) and many are continuing the investigation. I'm familiar with the theories (tho I must admit I hadn't come across that one), and I don't disagree with the general point. As you say there's an abundance of studies that support the idea that we have a limited mental work area. However, I don't think they should factor into decisions about how you organise your code because I see those as extremely subjective. The point I was trying to make (poorly it seems) was that if you follow common software engineering principals, use your common sense and refactor based on the logical way a problem breaks up into pieces, you'll usually end up with the same result. So why make the point? I hear you ask… I think the motivation behind architectural decisions, whether macro or micro, is fundamental. Making those decisions because you can see it all on your screen, or hold it all in your head, or any other I can do this therefore reason has great potential for resulting in code that's difficult for anyone but you to maintain. Let's say you're working on a text-only terminal. Your functions (or groups of logic to be more accurate) are likely to fit within 24 lines. Then you take on a project that's been developed by someone using a 30 monitor in portrait. She can see far more lines at once than you can. In fact she can see lines from multiple files at once. If their code structure has been determined by arbitrary, personal preferences such as how much they can see on the screen at once, their code will be a maintenance nightmare, especially for you on your 24-line terminal. That was the only point I was trying to make. Your observation is not wrong; it makes a lot of sense. However, I don't believe it should be given any further consideration than noting the observation, and you may want to consider what that observation means as far as the overall structure of your code. In essence you are writing more complex functions, because you can which I think is a very dangerous road to be on. As for the rest of your post, but of course, you are correct as you always are. You just missed the point that you are human and thus are subject to the same physical limits as the rest of us. Of course, you are free to think otherwise, but knowing you, the truth will eventually win out. :-) I am human, but we appear to see our limits differently. I see my limits as I'm fallible therefore the simpler I can make my code the more likely it is to behave the way I want, regardless of what level of complexity with which I think I'm capable of working whereas you see it in a similar way to Tony, where your limits are based on how much you can see at any one time. I'm not saying there's a
Re: [PHP] Function size
On May 29, 2012, at 10:20 AM, Stuart Dallas wrote: -snip- Besides, truth is subjective, but then so is everything, including that assertion. -Stuart You reply was longer than my monitor was high so I can't give an immediate reply -- I have to scroll. :-) However, with that said, you made good points and I don't disagree with any of them. As for me, I was speaking from my experience where the size of my functions over the last few decades has grown (up to a point) with my increasing monitor size. However, my eyesight has not improved and thus should be figured into this somehow. As I said before, mine is just an observation that supports the limits in reception/comprehension articles I have read. I think your 24 line terminal vs the 30 monitor argument is a valid one, up to a point. But I think the problems (if any) would depend upon many factors -- too numerous to elaborate here. But let me pose an idea. When I was in college, my degrees were in Geology. My Summer Field study (6 weeks) was to map out Geologic outcrops on a USGS topographic map. At the end of the study, all maps that matched the Professors' maps, were given the highest grades (mine the highest in all modesty). Not because they were alike, but because they approached the truth of the matter. The truth here was not subjective for there was only ONE defining truth and that could be discovered by detailed mapping. We all (including the Professors) approached the same problem in the same way and reached similar results. The closer to the truth, the more similar the maps. Over the years I've seen programming languages converge producing single solutions for common tasks, such as a FOR loop and IF statements. These seem to be universal constructs in programming logic. So my question is, as in my Geology study Is this convergence in programming logic discovering the truth of the task? Do you see what I mean? If so, then maybe the way we break down problems into smaller subsets might also be approaching an optimum method as well. I used to use (30+ years ago): 1) Input; 2) Calculation; 3) Display; as the main categories in my division logic to tackle problems and that was long before I heard of MVC. So, what I am saying is that we might all be approaching and contributing to an overall optimal logical solution in programming. Kind of an ant-colony think sort of thing. The solution is certainly not simple, but it might be an universally single solution to all the problems we perceive. Said only for Food for thought. Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
The art of software development is in taking a problem, breaking it up in to bite-size chunks, and putting those chunks together to form a practical solution. Anyone who considers themselves a better programmer because their functions are large due to their ability to handle large functions needs to keep their ego in check. Mental capacity has nothing to do with it. My philosophy for functions is simple... a function does one well-defined, discrete task, and it does it well. The inputs are clearly specified, and the potential outputs/exceptions are fully understood. Sound familiar? These requirements make it incredibly easy to write unit tests for the code. The number of times a function is used does not enter my field of interest. It's irrelevant, as is the number of lines in each function. Following this philosophy does naturally lead to fairly small functions, but as you move up the levels of abstraction they tend to grow larger. For PHP, I consider code in a file that's not within a function to be a function in itself, and the same philosophy applies. Stuart, Your philosophy is interesting. Of course, a function should have one well-defined and discrete task, but it is not always clear what one task is. Let me take an example of a list. For example, you want to write a function that removes an element from a list. In this example, we will only use this list to remove items from it, so the code required here won't be used another time. Now you have a few possibilities: 1) (This one is probably Tony's approach): Write a single function that searches the element and removes it from the list. 2) (My approach): Write a search function first, even though we're not going to use it elsewhere), then write a delete function that uses the search function to find it and remove it. 3) (Crazy approach ;)): Write a function that gets the next element in the list, write a search function that uses the previous one. Write a delete function that uses the search function, and then calls a function that removes the actual element. With your philosophy all three can fit. The other interesting part in this discussion is the limited mental work area. I assume that this is true, supported by the related studies, makes me feel that we should write code as compact as possible, right? - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On May 29, 2012, at 5:06 PM, Paul M Foster wrote: I think a lot of coders try to be kewler than the next 18 guys who are gonna have to look at the code, so they use a lot of compression techniques to reduce LOC. That's not kewl to me. Plus, they're lazy. I'd rather see everything with lots of spaces and plenty of comments and blank lines. Especially since I'm sometimes that 18th guy to look at the code. Paul Same here. Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On Tue, May 29, 2012 at 11:56:47AM -0400, Tedd Sperling wrote: On May 29, 2012, at 10:20 AM, Stuart Dallas wrote: -snip- Besides, truth is subjective, but then so is everything, including that assertion. -Stuart You reply was longer than my monitor was high so I can't give an immediate reply -- I have to scroll. :-) However, with that said, you made good points and I don't disagree with any of them. As for me, I was speaking from my experience where the size of my functions over the last few decades has grown (up to a point) with my increasing monitor size. However, my eyesight has not improved and thus should be figured into this somehow. As I said before, mine is just an observation that supports the limits in reception/comprehension articles I have read. I think your 24 line terminal vs the 30 monitor argument is a valid one, up to a point. But I think the problems (if any) would depend upon many factors -- too numerous to elaborate here. But let me pose an idea. When I was in college, my degrees were in Geology. My Summer Field study (6 weeks) was to map out Geologic outcrops on a USGS topographic map. At the end of the study, all maps that matched the Professors' maps, were given the highest grades (mine the highest in all modesty). Not because they were alike, but because they approached the truth of the matter. The truth here was not subjective for there was only ONE defining truth and that could be discovered by detailed mapping. We all (including the Professors) approached the same problem in the same way and reached similar results. The closer to the truth, the more similar the maps. Over the years I've seen programming languages converge producing single solutions for common tasks, such as a FOR loop and IF statements. These seem to be universal constructs in programming logic. So my question is, as in my Geology study Is this convergence in programming logic discovering the truth of the task? Do you see what I mean? If so, then maybe the way we break down problems into smaller subsets might also be approaching an optimum method as well. I used to use (30+ years ago): 1) Input; 2) Calculation; 3) Display; as the main categories in my division logic to tackle problems and that was long before I heard of MVC. So, what I am saying is that we might all be approaching and contributing to an overall optimal logical solution in programming. Kind of an ant-colony think sort of thing. The solution is certainly not simple, but it might be an universally single solution to all the problems we perceive. Said only for Food for thought. About 30 years ago, a guy wrote an essay about architectural stablization or somesuch. He was a computer guy who had written a whole office suite for 8 bit computers (called Valdocs, written for the Epson QX-10 computer, for you voracious learners). His point was that this phenomena was recognizable in many fields involving technology. For example, the architecture of automobiles eventually stabilized in such a way that these days, they pretty much all have steering wheels used for steering, four wheels, two headlights, etc. I think mainstream programming languages have probably done a lot of stabilization over the years. You do occasionally find weird languages like Lisp/Scheme, but in the main, most languages bear strong resemblance to C and Fortran. They're geared for slightly different environments or purposes, but syntactically, they bear strong resemblance to each other, compared to, say, APL or Lisp/Scheme. And to some extent they model how most people (programmers) would naturally approach the solution of programming problems. (Of course, there are always the oddballs like me who still prefer reverse polish notation on our calculators. Go figure.) Paul -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On 12-05-29 07:17 AM, Stuart Dallas wrote: I wasn't going to respond to this thread because I think it's a largely ridiculous topic, but some of the responses have scared me. Sir Cummings (hopefully) sarcastic response about using a 5px font size demonstrated how daft it is to base function size on how much code you can see on the screen at once. Guilty as charged ;) One time I was helping a friend of mine do his Java homework at Cornell and when he got the assignment back he scored 24 out of 25 and I was like What?!. The marker subtracted a point for a function that spanned more than one printed page. What a dork! I guess he didn't like my brace style since if I'd used a less vertically consumptive style then it would have printed cleanly on one page *lol*. Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On May 24, 2012, at 5:01 PM, Ashley Sheridan wrote: On Thu, 2012-05-24 at 15:48 -0500, tamouse mailing lists wrote: On May 23, 2012 9:14 AM, Tedd Sperling t...@sperling.com wrote: H Yes, I think that is *exactly* the criterion-- not a mystery or an emergent thing, really, was a pretty expicit reasoning--being able to see/scan the entire function on one page (or now in one screenful) makes it much easier to see what happens in the function, where blocks open/close, and it forces one to break up code into logical units. With the odd exception being where code is more readable in a longer format, as seen with my and several others examples of long functions that rely heavily on switches. -- Thanks, Ash Yep, not everything can it -- there are exceptions. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On Wed, May 23, 2012 at 10:14 PM, shiplu shiplu@gmail.com wrote: On Thu, May 24, 2012 at 1:56 AM, Matijn Woudt tijn...@gmail.com wrote: I agree that large switch block are not always easy and useful to split, however, writing too much code inside a switch block isn't considered good practice too IMO. Though, it is unavoidable in some cases I think. I do have some of these functions in my code too, I have one switch block of more than 500 lines, but that's just because I have more than 400 individual case statements, and I don't think there's a better way to do it. Doesn't mean I like it btw. I never encounter such big switch statement in PHP yet. However I saw huge switch and had to optimize it while working with a custom programming language interpreter written in C. When I see the language is OO, I try to apply polymorphic behavior and eliminate any switch statements. Here is a video that demonstrated the concept http://www.youtube.com/watch?v=4F72VULWFvc This is interesting. You do realize that if I would take this switch down to OO, I would have to create 400 different classes to replace this switch statement? Luckily in PHP we can have more classes in a single file, thinking about Java for example would mean I have to create 400 new files... I like the concept, but I don't see how it works for such switch statements. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Function size
My monitor can also display about 55 lines of code, my functions are, on
average, just a few lines of code though -- a maximum of about 20, with an
average of around 5 or so.
This is because the rule of thumb I follow is that a function should do
one
thing, and should be named well. The biggest downside to the type of style
I have is that if not done correctly, people can feel like they're
swimming in a sea of chasing down functions to find out wtf is going on.
When done correctly, it leads to pretty clear code, IMO.
--
Tedd,
I think the length of code depends on a few different factors, what if you
have your docblocks, and comment lines, as well as your bracing style?
Where do you consider your function to start?
Personally, I use this bracing style:
# decide if we should work, or sleep
if($do == $something)
{
# do something here
$work = 'done';
}
else
{
# something isn't being done now
$work = 'sleep';
}
In this (really crude) example, there are 11 lines of code. Granted, the
way you do your bracing you can lose a few lines, and within this example,
it could be written as:
# decide if we should work, or sleep
# default action for if something isn't being done
$work = 'sleep';
if($do == $something) {
# do something here
$work = 'done';
}
So, with that craptastic example, we've taken 11 lines, and compressed it to
7.
Anyways, I get the rule of thumb to be able to fit a function on a
screen, or to make it as small as possible, but sometimes comments can get
in the way, and if you like your bracing style, you end up with a lot of
extra lines of code too (also if you like to have blank lines between
actions).
Anyways, my IDE that I use, shows 47 lines on the screen, at 145 characters
across, using Courier New 9pt, and I try to keep it to 80 characters wide,
but that doesn't always happen :P
Steve.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
Steven Staples sstap...@mnsi.net writes: My monitor can also display about 55 lines of code, my functions are, on average, just a few lines of code though -- a maximum of about 20, with an average of around 5 or so. This is because the rule of thumb I follow is that a function should do one thing, and should be named well. The biggest downside to the type of style I have is that if not done correctly, people can feel like they're swimming in a sea of chasing down functions to find out wtf is going on. When done correctly, it leads to pretty clear code, IMO. -- Tedd, I think the length of code depends on a few different factors, what if you have your docblocks, and comment lines, as well as your bracing style? Where do you consider your function to start? I, and I'm fairly sure many others, do not count docblocks, comment lines, or lines containing only braces in the count for LOC in a function. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On May 23, 2012, at 3:49 PM, Ashley Sheridan wrote: I'm of the same mind. Generally I'll split a function if I'm reusing more than a couple of lines of code. I only split a large function if it's actually doing several things, if it happens to need 200 lines to perform one 'step' then I'll leave it as is. While I do prefer my functions to fit into a single 'screen', it rarely happens quite like that, because I move from screen to screen with different resolutions, so there's no constant limit for me. As a rough example, on a random selection of 27 functions taken from a controller on a site I worked on I get these general statistics: Functions: 27 Mean lines: 22.5 Mode lines: 3 Max lines: 218 The function with 218 lines is a large switch, and it doesn't make sense to do it any other way, because it would actually end up less readable. I see you and I are like minds in many ways. I had one large switch block that had 255 different cases. Oddly enough I was parsing a Tiger data file (USGS survey data) that contained 255 different record types. Each record type required a different function to parse the data and render it's portion of the overall map. That lead to me create a linked-list that held the memory addresses of both data and function. That way simply accessing the linked list coupled data to function and drew the map. It was neat. I find it also neat, while I'm not an expert on the subject, eliminating the need for 'switch' and 'if' statements via extending classes in OO. Shiplu provided a link, which I found interesting: http://www.youtube.com/watch?v=4F72VULWFvc It showed how one can eliminate such conditionals, but at the same time it massively increased the code to preform 1 + 2 * 3. :-) And to others, I don't need comment on how I missed the point -- I didn't. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On May 24, 2012, at 8:37 AM, Steven Staples wrote: Tedd, I think the length of code depends on a few different factors, what if you have your docblocks, and comment lines, as well as your bracing style? Where do you consider your function to start? It starts where it starts. It doesn't make any difference how you do it, it's what you see in one view that counts. If you are very verbose with spaces, brace styles, comments, and such, then your functions have less actual statement lines than others with more cryptic coding styles, but I would bet the line limit of total number of lines remain in place regardless. This is more a condition of physical/mental limits on humans than it is on coding style. So, there's no better or worse' point here -- it is more an observation. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Function size
Hi gang: On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote: A rule of thumb is no more than 50 lines per function, most much less. Back in the day when we didn't have nifty gui screens and an 24 line terminals (yay green on black!), if a function exceeded one printed page, it was deemed too long and marked for refactoring. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. I know from the last several decades of programming, my functions have increased in number of lines. But, they have reached a limit that limit is generally about the number of lines I can read in half of my monitor's height. This of course, is dependent on monitor resolution, font-size, and how far I am sitting from the monitor. But I think this is a natural and physical limit that we don't normally recognize. I can cite studies that support my theory. It would be an interesting survey to ask programmers to review their code and provide the average number of lines in their functions AND how many lines of code their monitor's can display. In other words, look at your editor; count the number of lines your monitor can display; estimate the number of lines in your average function; and report the findings. For example, mine is about half -- my monitor can display 55 lines of code and my average function is around 25 lines. YMMV. Interesting, yes? Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On Wed, May 23, 2012 at 8:14 PM, Tedd Sperling t...@sperling.com wrote: Hi gang: On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote: A rule of thumb is no more than 50 lines per function, most much less. Back in the day when we didn't have nifty gui screens and an 24 line terminals (yay green on black!), if a function exceeded one printed page, it was deemed too long and marked for refactoring. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? I follow this rule, *Each time I end up need a code block I wrote earlier, I convert it to a function. *So simple. This way you re-factor your code automatically and you dont do any copy paste. Last year someone on Stackoverflow asked something like this[1]. And that was my answer. [1] http://stackoverflow.com/a/8597409/376535 -- Shiplu.Mokadd.im ImgSign.com | A dynamic signature machine Innovation distinguishes between follower and leader
Re: [PHP] Function size
On May 23, 2012, at 11:49 AM, shiplu wrote: On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote: When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? You missed the point. Of course, the difficulty of the task of a specific function will directly contribute to the number of lines of code for that function, but that's not what I was talking about. What I was talking about was that what we can grasp in one view, we can understand better. If the code lies outside of our view, then we understand it less. I can support this claim with numerous articles/books/studies of human visual limits vs short-term memory. I am only bringing this forward for us to consider in our writing code. If we know why we do things, then we can better understand what we do. Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On 12-05-23 12:15 PM, Tedd Sperling wrote: On May 23, 2012, at 11:49 AM, shiplu wrote: On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote: When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? You missed the point. Of course, the difficulty of the task of a specific function will directly contribute to the number of lines of code for that function, but that's not what I was talking about. What I was talking about was that what we can grasp in one view, we can understand better. If the code lies outside of our view, then we understand it less. I can support this claim with numerous articles/books/studies of human visual limits vs short-term memory. I am only bringing this forward for us to consider in our writing code. If we know why we do things, then we can better understand what we do. That's why I code in 5px font. On my huge monitor I sometimes find the code is shaped like a tiger, or a dragon, I swear I even saw Piccolo. It really does help to see the big picture :B Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On Wed, May 23, 2012 at 5:49 PM, shiplu shiplu@gmail.com wrote: On Wed, May 23, 2012 at 8:14 PM, Tedd Sperling t...@sperling.com wrote: Hi gang: On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote: A rule of thumb is no more than 50 lines per function, most much less. Back in the day when we didn't have nifty gui screens and an 24 line terminals (yay green on black!), if a function exceeded one printed page, it was deemed too long and marked for refactoring. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? I follow this rule, *Each time I end up need a code block I wrote earlier, I convert it to a function. *So simple. This way you re-factor your code automatically and you dont do any copy paste. Last year someone on Stackoverflow asked something like this[1]. And that was my answer. Hi, While this could be one reason to start a new function, it should not (IMO) be the only reason. Sometimes you can have a large complicated function, with say 200 LOC. While I wouldn't need any of these lines a second time, I usually try to rip blocks of say 50 lines out and put it in a seperate function, so that the main function itself is easier to understand. - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On May 23, 2012, at 12:21 PM, Robert Cummings wrote: On 12-05-23 12:15 PM, Tedd Sperling wrote: What I was talking about was that what we can grasp in one view, we can understand better. If the code lies outside of our view, then we understand it less. I can support this claim with numerous articles/books/studies of human visual limits vs short-term memory. I am only bringing this forward for us to consider in our writing code. If we know why we do things, then we can better understand what we do. That's why I code in 5px font. On my huge monitor I sometimes find the code is shaped like a tiger, or a dragon, I swear I even saw Piccolo. It really does help to see the big picture :B Cheers, Rob. Forgive me -- I should have know better. This is a bit like talking to my grandkids -- if it doesn't involve dulling crayons, there's no point. :-) Cheers, tedd _ t...@sperling.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
On Wed, 2012-05-23 at 20:59 +0200, Matijn Woudt wrote: On Wed, May 23, 2012 at 5:49 PM, shiplu shiplu@gmail.com wrote: On Wed, May 23, 2012 at 8:14 PM, Tedd Sperling t...@sperling.com wrote: Hi gang: On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote: A rule of thumb is no more than 50 lines per function, most much less. Back in the day when we didn't have nifty gui screens and an 24 line terminals (yay green on black!), if a function exceeded one printed page, it was deemed too long and marked for refactoring. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? I follow this rule, *Each time I end up need a code block I wrote earlier, I convert it to a function. *So simple. This way you re-factor your code automatically and you dont do any copy paste. Last year someone on Stackoverflow asked something like this[1]. And that was my answer. Hi, While this could be one reason to start a new function, it should not (IMO) be the only reason. Sometimes you can have a large complicated function, with say 200 LOC. While I wouldn't need any of these lines a second time, I usually try to rip blocks of say 50 lines out and put it in a seperate function, so that the main function itself is easier to understand. - Matijn I'm of the same mind. Generally I'll split a function if I'm reusing more than a couple of lines of code. I only split a large function if it's actually doing several things, if it happens to need 200 lines to perform one 'step' then I'll leave it as is. While I do prefer my functions to fit into a single 'screen', it rarely happens quite like that, because I move from screen to screen with different resolutions, so there's no constant limit for me. As a rough example, on a random selection of 27 functions taken from a controller on a site I worked on I get these general statistics: Functions: 27 Mean lines: 22.5 Mode lines: 3 Max lines: 218 The function with 218 lines is a large switch, and it doesn't make sense to do it any other way, because it would actually end up less readable. -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Function size
On Wed, May 23, 2012 at 9:49 PM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: ** On Wed, 2012-05-23 at 20:59 +0200, Matijn Woudt wrote: On Wed, May 23, 2012 at 5:49 PM, shiplu shiplu@gmail.com wrote: On Wed, May 23, 2012 at 8:14 PM, Tedd Sperling t...@sperling.com wrote: Hi gang: On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote: A rule of thumb is no more than 50 lines per function, most much less. Back in the day when we didn't have nifty gui screens and an 24 line terminals (yay green on black!), if a function exceeded one printed page, it was deemed too long and marked for refactoring. You hit upon a theory of mine -- and that is our functions grow in size up to our ability to view them in their totality. When our functions get beyond that limit, we tend to refactor and reduce. When number of lines becomes the criteria of function size? Wouldn't it depends on the task the function is doing? I follow this rule, *Each time I end up need a code block I wrote earlier, I convert it to a function. *So simple. This way you re-factor your code automatically and you dont do any copy paste. Last year someone on Stackoverflow asked something like this[1]. And that was my answer. Hi, While this could be one reason to start a new function, it should not (IMO) be the only reason. Sometimes you can have a large complicated function, with say 200 LOC. While I wouldn't need any of these lines a second time, I usually try to rip blocks of say 50 lines out and put it in a seperate function, so that the main function itself is easier to understand. - Matijn I'm of the same mind. Generally I'll split a function if I'm reusing more than a couple of lines of code. I only split a large function if it's actually doing several things, if it happens to need 200 lines to perform one 'step' then I'll leave it as is. While I do prefer my functions to fit into a single 'screen', it rarely happens quite like that, because I move from screen to screen with different resolutions, so there's no constant limit for me. As a rough example, on a random selection of 27 functions taken from a controller on a site I worked on I get these general statistics: Functions: 27 Mean lines: 22.5 Mode lines: 3 Max lines: 218 The function with 218 lines is a large switch, and it doesn't make sense to do it any other way, because it would actually end up less readable. I agree that large switch block are not always easy and useful to split, however, writing too much code inside a switch block isn't considered good practice too IMO. Though, it is unavoidable in some cases I think. I do have some of these functions in my code too, I have one switch block of more than 500 lines, but that's just because I have more than 400 individual case statements, and I don't think there's a better way to do it. Doesn't mean I like it btw.. - Matijn
Re: [PHP] Function size
On Thu, May 24, 2012 at 1:56 AM, Matijn Woudt tijn...@gmail.com wrote: I agree that large switch block are not always easy and useful to split, however, writing too much code inside a switch block isn't considered good practice too IMO. Though, it is unavoidable in some cases I think. I do have some of these functions in my code too, I have one switch block of more than 500 lines, but that's just because I have more than 400 individual case statements, and I don't think there's a better way to do it. Doesn't mean I like it btw. I never encounter such big switch statement in PHP yet. However I saw huge switch and had to optimize it while working with a custom programming language interpreter written in C. When I see the language is OO, I try to apply polymorphic behavior and eliminate any switch statements. Here is a video that demonstrated the concept http://www.youtube.com/watch?v=4F72VULWFvc -- Shiplu.Mokadd.im ImgSign.com | A dynamic signature machine Innovation distinguishes between follower and leader
Re: [PHP] Function size
I use a lot of switches but they are always small in size because they look
mostly like this:
switch($action) {
case 'hello':
$someObject-executeAction();
break;
case 'world':
$someOtherObject-executeOtherAction();
break;
default:
$this-anotherAction();
break;
}
Maybe it's not the rule for some really specific small functionality which I
know I won't be using ever again, but that's the latest trend I've acquired in
order to improve readability. Personally I find that the particular switch
statement disorders the code, but at least it is a lot better than a lot of
if/elses xD
Haven't you tried this approach or does that particular function do have a lot
of cases?
Greetings.
On 23 mei 2012, at 21:49, Ashley Sheridan wrote:
On Wed, 2012-05-23 at 20:59 +0200, Matijn Woudt wrote:
On Wed, May 23, 2012 at 5:49 PM, shiplu shiplu@gmail.com wrote:
On Wed, May 23, 2012 at 8:14 PM, Tedd Sperling t...@sperling.com wrote:
Hi gang:
On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote:
A rule of thumb is no more than 50 lines per
function, most much less. Back in the day when we didn't have nifty
gui screens and an 24 line terminals (yay green on black!), if a
function exceeded one printed page, it was deemed too long and marked
for refactoring.
You hit upon a theory of mine -- and that is our functions grow in size up
to our ability to view them in their totality. When our functions get
beyond that limit, we tend to refactor and reduce.
When number of lines becomes the criteria of function size? Wouldn't it
depends on the task the function is doing? I follow this rule, *Each time I
end up need a code block I wrote earlier, I convert it to a function. *So
simple. This way you re-factor your code automatically and you dont do any
copy paste. Last year someone on Stackoverflow asked something like
this[1]. And that was my answer.
Hi,
While this could be one reason to start a new function, it should not
(IMO) be the only reason. Sometimes you can have a large complicated
function, with say 200 LOC. While I wouldn't need any of these lines a
second time, I usually try to rip blocks of say 50 lines out and put
it in a seperate function, so that the main function itself is easier
to understand.
- Matijn
I'm of the same mind. Generally I'll split a function if I'm reusing
more than a couple of lines of code. I only split a large function if
it's actually doing several things, if it happens to need 200 lines to
perform one 'step' then I'll leave it as is. While I do prefer my
functions to fit into a single 'screen', it rarely happens quite like
that, because I move from screen to screen with different resolutions,
so there's no constant limit for me.
As a rough example, on a random selection of 27 functions taken from a
controller on a site I worked on I get these general statistics:
Functions: 27
Mean lines: 22.5
Mode lines: 3
Max lines: 218
The function with 218 lines is a large switch, and it doesn't make sense
to do it any other way, because it would actually end up less readable.
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function size
Tedd Sperling t...@sperling.com writes: It would be an interesting survey to ask programmers to review their code and provide the average number of lines in their functions AND how many lines of code their monitor's can display. In other words, look at your editor; count the number of lines your monitor can display; estimate the number of lines in your average function; and report the findings. For example, mine is about half -- my monitor can display 55 lines of code and my average function is around 25 lines. YMMV. Interesting, yes? Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com My monitor can also display about 55 lines of code, my functions are, on average, just a few lines of code though -- a maximum of about 20, with an average of around 5 or so. This is because the rule of thumb I follow is that a function should do one thing, and should be named well. The biggest downside to the type of style I have is that if not done correctly, people can feel like they're swimming in a sea of chasing down functions to find out wtf is going on. When done correctly, it leads to pretty clear code, IMO. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function
On Fri, May 4, 2012 at 4:29 AM, Dan Joseph dmjos...@gmail.com wrote:
Are these inside classes or anything? If they're just functions, they
should work fine together, example of 2 working functions together:
?php
hellotwo();
function helloone()
{
echo hi 1;
}
function hellotwo()
{
helloone();
}
?
This results in hi 1 being echoed to the screen.
--
-Dan Joseph
http://www.danjoseph.me
Hi, Ron
Another hint:
Maybe the other function (you want to call inside your first function)
is not defined at that time but in a file that's included later on ...
Bye
Simon
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function
On Thu, May 3, 2012 at 9:12 PM, Ron Piggott
ron.pigg...@actsministries.org wrote:
I need to access a FUNCTION I programmed within a different FUNCTION. Are
these able to be passed like a variable? Or are they able to become like a
$_SESSION variable in nature? How am I able to do this?
I am essentially programming:
===
function name( $flag1, $flag2 ) {
# some PHP
echo name_of_a_different_function( $flag1 , $flag2 );
}
===
The error I am receiving is “Call to undefined function
name_of_a_different_function”
Where is name_of_a_different_function defined? If it is somewhere in
the same file as name, that shouldn't be a problem, provided it is
defined in the same namespace/scope as name. If it is defined in a
different file, you need to include that file before you make the echo
statement.
For example:
function func1 ($flag1, $flag2) {
# blah blah
echo func2($flag1, $flag2);
}
function func2 ($flag1, $flag2) {
#blah blah
return some string value;
}
in the same file should be just fine. It doesn't really matter what
order func1 and func2 are declared in.
However, if func2 is defined in some_other_file.php, you need to
include it in this_file.php (where func1 is defined) first:
this_file.php:
include('some_other_file.php');
function func1 ($flag1, $flag2) {
#blah blah
echo func2 ($flag1, $flag2);
}
some_other_file.php:
function func2 ($flag1, $flag2) {
#blah blah
return some string value;
}
If func2 is a method for an object/class, you'll have to access it
that way in func1:
this_file.php:
include('MyClass.php');
function func1 ($flag1, $flag2) {
# blah blah, instantiate object?
$myobj = new MyClass();
echo $myobj-func2 ($flag1, $flag2);
}
MyClass.php:
class MyClass
{
function func2 ($flag1, $flag2) {
#blah blah
return some string value;
}
}
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function
But the OP says function is defined inside a different function. Your
theories to a solution don't fit that problem.
tamouse mailing lists tamouse.li...@gmail.com wrote in message
news:cahuc_t-416_-lpcn3mo8qqxwrh4pnq5fmwouhwpdk+hmkgh...@mail.gmail.com...
On Thu, May 3, 2012 at 9:12 PM, Ron Piggott
ron.pigg...@actsministries.org wrote:
Where is name_of_a_different_function defined? If it is somewhere in
the same file as name, that shouldn't be a problem, provided it is
defined in the same namespace/scope as name. If it is defined in a
different file, you need to include that file before you make the echo
statement.
For example:
function func1 ($flag1, $flag2) {
# blah blah
echo func2($flag1, $flag2);
}
function func2 ($flag1, $flag2) {
#blah blah
return some string value;
}
in the same file should be just fine. It doesn't really matter what
order func1 and func2 are declared in.
However, if func2 is defined in some_other_file.php, you need to
include it in this_file.php (where func1 is defined) first:
this_file.php:
include('some_other_file.php');
function func1 ($flag1, $flag2) {
#blah blah
echo func2 ($flag1, $flag2);
}
some_other_file.php:
function func2 ($flag1, $flag2) {
#blah blah
return some string value;
}
If func2 is a method for an object/class, you'll have to access it
that way in func1:
this_file.php:
include('MyClass.php');
function func1 ($flag1, $flag2) {
# blah blah, instantiate object?
$myobj = new MyClass();
echo $myobj-func2 ($flag1, $flag2);
}
MyClass.php:
class MyClass
{
function func2 ($flag1, $flag2) {
#blah blah
return some string value;
}
}
But the OP says function is defined inside a different function. Your
theories to a solution don't fit that problem.
(Sorry you all had to read thru so much stuff just to get to my one-line
response.)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function
On Fri, May 4, 2012 at 9:18 PM, Jim Giner jim.gi...@albanyhandball.com wrote: But the OP says function is defined inside a different function. Your theories to a solution don't fit that problem. [snip] But the OP says function is defined inside a different function. Your theories to a solution don't fit that problem. (Sorry you all had to read thru so much stuff just to get to my one-line response.) There's no need to include something if it turns out to be irrelevant. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function
On Thu, May 3, 2012 at 9:12 PM, Ron Piggott
ron.pigg...@actsministries.org wrote:
I need to access a FUNCTION I programmed within a different FUNCTION. Are
these able to be passed like a variable? Or are they able to become like a
$_SESSION variable in nature? How am I able to do this?
I am essentially programming:
===
function name( $flag1, $flag2 ) {
# some PHP
echo name_of_a_different_function( $flag1 , $flag2 );
}
===
The error I am receiving is “Call to undefined function
name_of_a_different_function”
Thanks to Jim, I understand a bit more, however, I still do not see
where name_of_a_different_function is being defined. Rather than
suppose something, please post the function where
name_of_a_different_function is defined.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] function
I need to access a FUNCTION I programmed within a different FUNCTION. Are
these able to be passed like a variable? Or are they able to become like a
$_SESSION variable in nature? How am I able to do this?
I am essentially programming:
===
function name( $flag1, $flag2 ) {
# some PHP
echo name_of_a_different_function( $flag1 , $flag2 );
}
===
The error I am receiving is “Call to undefined function
name_of_a_different_function”
Thanks, Ron
Ron Piggott
www.TheVerseOfTheDay.info
Re: [PHP] function
On Thu, May 3, 2012 at 10:12 PM, Ron Piggott ron.pigg...@actsministries.org
wrote:
I need to access a FUNCTION I programmed within a different FUNCTION. Are
these able to be passed like a variable? Or are they able to become like a
$_SESSION variable in nature? How am I able to do this?
I am essentially programming:
===
function name( $flag1, $flag2 ) {
# some PHP
echo name_of_a_different_function( $flag1 , $flag2 );
}
===
The error I am receiving is “Call to undefined function
name_of_a_different_function”
Are these inside classes or anything? If they're just functions, they
should work fine together, example of 2 working functions together:
?php
hellotwo();
function helloone()
{
echo hi 1;
}
function hellotwo()
{
helloone();
}
?
This results in hi 1 being echoed to the screen.
--
-Dan Joseph
http://www.danjoseph.me
Re: [PHP] Function mktime() documentation question
On Mar 11, 2012, at 3:10 PM, Matijn Woudt wrote:
On Sun, Mar 11, 2012 at 7:33 PM, Tedd Sperling tedd.sperl...@gmail.com
wrote:
Actually, this works for me:
$days_in_month = date('t', mktime(0, 0, 0, $next_month, 0, $year));
But again, I don't see why I have to use next month to find the number of
days in this month.
That's because you're requesting day 0 of some month, which refers to
the last day in the previous month.
Try: $days_in_month = date('t', mktime(0, 0, 0, $next_month, 1, $year));
- Matijn
I got that.
Beating the same dead horse again, I think day 0 of this month should contain
the days in this month, but I am in the minority on this.
Cheers,
tedd
_
tedd.sperl...@gmail.com
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Mon, 2012-03-12 at 15:53 -0400, Tedd Sperling wrote:
On Mar 11, 2012, at 3:10 PM, Matijn Woudt wrote:
On Sun, Mar 11, 2012 at 7:33 PM, Tedd Sperling tedd.sperl...@gmail.com
wrote:
Actually, this works for me:
$days_in_month = date('t', mktime(0, 0, 0, $next_month, 0, $year));
But again, I don't see why I have to use next month to find the number
of days in this month.
That's because you're requesting day 0 of some month, which refers to
the last day in the previous month.
Try: $days_in_month = date('t', mktime(0, 0, 0, $next_month, 1, $year));
- Matijn
I got that.
Beating the same dead horse again, I think day 0 of this month should contain
the days in this month, but I am in the minority on this.
Cheers,
tedd
_
tedd.sperl...@gmail.com
http://sperling.com
I think a lot of the confusion is that we're so used to array indexes
beginning at 0 that we tend to assume other things should start there
too. I found this confusing when I first came across the date stuff in
PHP. Now I'm used to it, it makes sense.
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [PHP] Function mktime() documentation question
On Sat, 2012-03-10 at 20:38 -0500, Tedd Sperling wrote:
On Mar 10, 2012, at 12:20 PM, Maciek Sokolewicz wrote:
function getAmountOfDaysInAMonth($month, $year) {
$days = array(31, (($year%4==0 and ($year%100 0 or $year%400==0)) ? 29
: 28), 31, 30, 31, 30, 31, 31, 30, 31, 30, 31);
return $days[$month+1];
}
I like that -- here's a small variation.
function numberDaysMonth($month, $year)
{
// Leap year is definded as a year that is evenly divisible by four
// AND (year NOT evenly divisible by 100 OR year IS evenly divisible by
400)
$feb = ($year%4 == 0 ($year%100 != 0 || $year%400 == 0) ) ? 29 : 28;
$days = array(0, 31, $feb, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31);
return $days[$month];
}
Cheers,
tedd
_
tedd.sperl...@gmail.com
http://sperling.com
I still don't see what's wrong with
date(t);
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [PHP] Function mktime() documentation question
On Mar 11, 2012, at 6:12 AM, Ashley Sheridan wrote:
I still don't see what's wrong with
date(t);
--
Thanks,
Ash
Ash:
It's just too damn simple -- we need to make things complicated. :-)
Actually, this works for me:
$days_in_month = date('t', mktime(0, 0, 0, $next_month, 0, $year));
But again, I don't see why I have to use next month to find the number of
days in this month.
O', the mysteries of life.
Cheers,
tedd
_
tedd.sperl...@gmail.com
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Sun, Mar 11, 2012 at 7:33 PM, Tedd Sperling tedd.sperl...@gmail.com wrote:
On Mar 11, 2012, at 6:12 AM, Ashley Sheridan wrote:
I still don't see what's wrong with
date(t);
--
Thanks,
Ash
Ash:
It's just too damn simple -- we need to make things complicated. :-)
Actually, this works for me:
$days_in_month = date('t', mktime(0, 0, 0, $next_month, 0, $year));
But again, I don't see why I have to use next month to find the number of
days in this month.
That's because you're requesting day 0 of some month, which refers to
the last day in the previous month.
Try: $days_in_month = date('t', mktime(0, 0, 0, $next_month, 1, $year));
- Matijn
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On 09-03-2012 14:11, Daniel Brown wrote:
(To the list, as well. First day with my new fingers, apparently)
On Fri, Mar 9, 2012 at 08:09, Daniel Browndanbr...@php.net wrote:
On Thu, Mar 8, 2012 at 21:23, Tedd Sperlingtedd.sperl...@gmail.com wrote:
This starts getting a bit off-topic from your original email, but
knowing that you're trying to use it for teaching your classes at the
college, it may be of some value to you.
All of this aside, though, you may instead want to use something along the
lines of date('d',strtotime('last day of this month')); in tandem with your
date formatting.
That's a good idea, but
date('d',strtotime('last day of this month'));
gives me the number of days in *this* month, but not the next, or previous,
month.
I need the result to be whatever date was selected -- something like:
$number_days = date('d',strtotime('last day of April, 2014'));
But that doesn't work.
Sure it does, though you may have some issues when using
punctuation, unnecessary words, or using capital letters for anything
other than proper names. What version of PHP are you using? I get
the correct answers for all of the following phrases:
last day of April 2014
last day of this month
last day of next month
last day of last month
third Saturday March 2012
Or you can even be excruciatingly redundant:
echo date('d',strtotime('last day of this
month',strtotime('next month')));
echo date('d',strtotime('last day of this
month',strtotime('February 2018')));
echo date('d',strtotime('second Monday',strtotime('September 2012')));
I must admit I'm still at a loss why people would want a function to
tell them the amount of days in a month. That amount is pretty much
fixed (except for february, but that's also mathematically easy to fix).
So a simple function like:
function getAmountOfDaysInAMonth($month, $year) {
$days = array(31, (($year%4==0 and ($year%100 0 or $year%400==0))
? 29 : 28), 31, 30, 31, 30, 31, 31, 30, 31, 30, 31);
return $days[$month+1];
}
Would work just fine. Unless of course you want to count the amount of
days during the changing of calendars (ie during the change of the
julian calendar to the gregorian), or in different calendars altogether.
Why (ab)use the datetime library for such a very simple thing? In the
last case, I would indeed use DateTime, simply because it's not an easy
answer.
- Tul
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Sat, Mar 10, 2012 at 6:20 PM, Maciek Sokolewicz
maciek.sokolew...@gmail.com wrote:
On 09-03-2012 14:11, Daniel Brown wrote:
(To the list, as well. First day with my new fingers, apparently)
On Fri, Mar 9, 2012 at 08:09, Daniel Browndanbr...@php.net wrote:
On Thu, Mar 8, 2012 at 21:23, Tedd Sperlingtedd.sperl...@gmail.com
wrote:
This starts getting a bit off-topic from your original email, but
knowing that you're trying to use it for teaching your classes at the
college, it may be of some value to you.
All of this aside, though, you may instead want to use something along
the lines of date('d',strtotime('last day of this month')); in tandem with
your date formatting.
That's a good idea, but
date('d',strtotime('last day of this month'));
gives me the number of days in *this* month, but not the next, or
previous, month.
I need the result to be whatever date was selected -- something like:
$number_days = date('d',strtotime('last day of April, 2014'));
But that doesn't work.
Sure it does, though you may have some issues when using
punctuation, unnecessary words, or using capital letters for anything
other than proper names. What version of PHP are you using? I get
the correct answers for all of the following phrases:
last day of April 2014
last day of this month
last day of next month
last day of last month
third Saturday March 2012
Or you can even be excruciatingly redundant:
echo date('d',strtotime('last day of this
month',strtotime('next month')));
echo date('d',strtotime('last day of this
month',strtotime('February 2018')));
echo date('d',strtotime('second Monday',strtotime('September
2012')));
I must admit I'm still at a loss why people would want a function to tell
them the amount of days in a month. That amount is pretty much fixed (except
for february, but that's also mathematically easy to fix). So a simple
function like:
function getAmountOfDaysInAMonth($month, $year) {
$days = array(31, (($year%4==0 and ($year%100 0 or $year%400==0)) ? 29 :
28), 31, 30, 31, 30, 31, 31, 30, 31, 30, 31);
return $days[$month+1];
}
Shouldn't this be $month-1?
- Matijn
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On 10 March 2012 19:06, Matijn Woudt tijn...@gmail.com wrote:
On Sat, Mar 10, 2012 at 6:20 PM, Maciek Sokolewicz
maciek.sokolew...@gmail.com wrote:
On 09-03-2012 14:11, Daniel Brown wrote:
(To the list, as well. First day with my new fingers,
apparently)
On Fri, Mar 9, 2012 at 08:09, Daniel Browndanbr...@php.net wrote:
On Thu, Mar 8, 2012 at 21:23, Tedd Sperlingtedd.sperl...@gmail.com
wrote:
This starts getting a bit off-topic from your original email, but
knowing that you're trying to use it for teaching your classes at the
college, it may be of some value to you.
All of this aside, though, you may instead want to use something
along
the lines of date('d',strtotime('last day of this month')); in
tandem with
your date formatting.
That's a good idea, but
date('d',strtotime('last day of this month'));
gives me the number of days in *this* month, but not the next, or
previous, month.
I need the result to be whatever date was selected -- something like:
$number_days = date('d',strtotime('last day of April, 2014'));
But that doesn't work.
Sure it does, though you may have some issues when using
punctuation, unnecessary words, or using capital letters for anything
other than proper names. What version of PHP are you using? I get
the correct answers for all of the following phrases:
last day of April 2014
last day of this month
last day of next month
last day of last month
third Saturday March 2012
Or you can even be excruciatingly redundant:
echo date('d',strtotime('last day of this
month',strtotime('next month')));
echo date('d',strtotime('last day of this
month',strtotime('February 2018')));
echo date('d',strtotime('second Monday',strtotime('September
2012')));
I must admit I'm still at a loss why people would want a function to tell
them the amount of days in a month. That amount is pretty much fixed
(except
for february, but that's also mathematically easy to fix). So a simple
function like:
function getAmountOfDaysInAMonth($month, $year) {
$days = array(31, (($year%4==0 and ($year%100 0 or $year%400==0)) ?
29 :
28), 31, 30, 31, 30, 31, 31, 30, 31, 30, 31);
return $days[$month+1];
}
Shouldn't this be $month-1?
- Matijn
Ehr, sorry, yes, you're right; well spotted! :)
- Tul
Re: [PHP] Function mktime() documentation question
I'm just a bit baffled why this isn't a standard library function. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Sat, Mar 10, 2012 at 9:47 PM, tamouse mailing lists tamouse.li...@gmail.com wrote: I'm just a bit baffled why this isn't a standard library function. Good question, but I think the problem here is that there are tons of these small functions, and you got to make a choice on what to implement and what not. I can think of at least 20 other functions I'd like to have integrated, but IMO PHP shouldn't be bloated with tons of just 'useful' functions. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Mar 10, 2012, at 12:20 PM, Maciek Sokolewicz wrote:
function getAmountOfDaysInAMonth($month, $year) {
$days = array(31, (($year%4==0 and ($year%100 0 or $year%400==0)) ? 29 :
28), 31, 30, 31, 30, 31, 31, 30, 31, 30, 31);
return $days[$month+1];
}
I like that -- here's a small variation.
function numberDaysMonth($month, $year)
{
// Leap year is definded as a year that is evenly divisible by four
// AND (year NOT evenly divisible by 100 OR year IS evenly divisible by
400)
$feb = ($year%4 == 0 ($year%100 != 0 || $year%400 == 0) ) ? 29 : 28;
$days = array(0, 31, $feb, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31);
return $days[$month];
}
Cheers,
tedd
_
tedd.sperl...@gmail.com
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Function mktime() documentation question
-Original Message- From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] Sent: 08 March 2012 23:15 To: PHP-General List [previous discussion snipped] Mike: Very well put. You say: Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. That IS exactly what I am saying. But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? Actually, no. To figure this out, somewhere along the line you've got to know where the last day of this month / first day of next month boundary lies, so I don't see how you can ever find the number of days in a month without bringing the start of next month into it somehow. (Even if it's implicitly be getting someone else's clever code to figure out 'last day of this month'!) It would have been better if one could use: $what_date = getdate(mktime(0, 0, 0, $this_month, 0, $year)); $days_in_this_month = $what_date['nday']; // note an additional key for getdate() But that $what_date would still refer to a day in *last* month! (Which isn't going to change, as it would be a significant BC break.) But instead, we have to use: $next_month = $this_month +1; $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year)); $days_in_this_month = $what_date['mday']; To me, that's a clever and elegant solution. It's clear that our brains just work differently on this one. Additionally, there's a perception problem. You say that 0 of the next month *is* the last day of the current month -- as such, apparently months overlap in your (and Dan's) explanation. Well... I agree with both of you, but my objection is having to increase the month value by one to get the number of days in the current month. Not overlap as such, I don't think -- there's just a continuum such that the 0th of a month is the day before the 1st (and hence the last day of the preceding month!), the -1th is the day before that and so on; likewise, the 32nd is the day after the 31st, and so on. Side-point: I find it interesting that getdate() has all sorts of neat descriptions for the current month (such as, what weekday a numbered day is), but lacks how many days are in the month. Doesn't that seem odd? Now that's a decent point: I can see where you're coming from with that one. I don't know what performance penalty there might be (if any) to calculate that for every call to getdate(), but it certainly seems like a reasonable feature request. (And, actually, I think we should be quite grateful that mktime() *does* take out-of-range values and do appropriate things with them -- if it didn't, I suspect the only way to do this job might be a loop similar to the one posted by Tedd, but adding chunks of 86400 to a raw timestamp. Now that really would be a bit obscure!!!) Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Portland PD507, City Campus, Leeds Metropolitan University, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
Ford, Mike wrote: Side-point: I find it interesting that getdate() has all sorts of neat descriptions for the current month (such as, what weekday a numbered day is), but lacks how many days are in the month. Doesn't that seem odd? Now that's a decent point: I can see where you're coming from with that one. I don't know what performance penalty there might be (if any) to calculate that for every call to getdate(), but it certainly seems like a reasonable feature request. I've never had this problem ;) http://phplens.com/phpeverywhere/adodb_date_library -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
(To the list, as well. First day with my new fingers, apparently)
On Fri, Mar 9, 2012 at 08:09, Daniel Brown danbr...@php.net wrote:
On Thu, Mar 8, 2012 at 21:23, Tedd Sperling tedd.sperl...@gmail.com wrote:
This starts getting a bit off-topic from your original email, but
knowing that you're trying to use it for teaching your classes at the
college, it may be of some value to you.
All of this aside, though, you may instead want to use something along the
lines of date('d',strtotime('last day of this month')); in tandem with your
date formatting.
That's a good idea, but
date('d',strtotime('last day of this month'));
gives me the number of days in *this* month, but not the next, or previous,
month.
I need the result to be whatever date was selected -- something like:
$number_days = date('d',strtotime('last day of April, 2014'));
But that doesn't work.
Sure it does, though you may have some issues when using
punctuation, unnecessary words, or using capital letters for anything
other than proper names. What version of PHP are you using? I get
the correct answers for all of the following phrases:
last day of April 2014
last day of this month
last day of next month
last day of last month
third Saturday March 2012
Or you can even be excruciatingly redundant:
echo date('d',strtotime('last day of this
month',strtotime('next month')));
echo date('d',strtotime('last day of this
month',strtotime('February 2018')));
echo date('d',strtotime('second Monday',strtotime('September 2012')));
--
/Daniel P. Brown
Network Infrastructure Manager
http://www.php.net/
--
/Daniel P. Brown
Network Infrastructure Manager
http://www.php.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote: From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? Actually, no. To figure this out, somewhere along the line you've got to know where the last day of this month / first day of next month boundary lies, so I don't see how you can ever find the number of days in a month without bringing the start of next month into it somehow. (Even if it's implicitly be getting someone else's clever code to figure out 'last day of this month'!) Well no, I don't need to know the first day of next month to know the last day of this month. That's like saying I need to know who is going to stand at the 'end of the line' NEXT before I can tell who is standing at the 'end of the' line NOW. I like things to be self-contained. For the exception of multiverse arguments, everything should be self evident. But instead, we have to use: $next_month = $this_month +1; $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year)); $days_in_this_month = $what_date['mday']; To me, that's a clever and elegant solution. It's clear that our brains just work differently on this one. We all have differences in perception, how we analyze problems, and how we create solutions -- and that's a good thing. Side-point: I find it interesting that getdate() has all sorts of neat descriptions for the current month (such as, what weekday a numbered day is), but lacks how many days are in the month. Doesn't that seem odd? Now that's a decent point: I can see where you're coming from with that one. I don't know what performance penalty there might be (if any) to calculate that for every call to getdate(), but it certainly seems like a reasonable feature request. I'm glad I have a decent point somewhere in this exchange and that we agree on something. :-) Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote: From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? Actually, no. To figure this out, somewhere along the line you've got to know where the last day of this month / first day of next month boundary lies, so I don't see how you can ever find the number of days in a month without bringing the start of next month into it somehow. (Even if it's implicitly be getting someone else's clever code to figure out 'last day of this month'!) Well no, I don't need to know the first day of next month to know the last day of this month. That's like saying I need to know who is going to stand at the 'end of the line' NEXT before I can tell who is standing at the 'end of the' line NOW. The number of days in each month is fixed, except for february. If that's what you want, why don't make a table of the number of days in each month, and check for the special case of leap year. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Mar 9, 2012, at 11:17 AM, Charles wrote: On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote: From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? Actually, no. To figure this out, somewhere along the line you've got to know where the last day of this month / first day of next month boundary lies, so I don't see how you can ever find the number of days in a month without bringing the start of next month into it somehow. (Even if it's implicitly be getting someone else's clever code to figure out 'last day of this month'!) Well no, I don't need to know the first day of next month to know the last day of this month. That's like saying I need to know who is going to stand at the 'end of the line' NEXT before I can tell who is standing at the 'end of the' line NOW. The number of days in each month is fixed, except for february. If that's what you want, why don't make a table of the number of days in each month, and check for the special case of leap year. No offense, but that's not the point. A look-up table would work, but why when there are all sorts of built-in functions that will? I am just looking for one that is easy to explain to students. Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Sat, Mar 10, 2012 at 12:07 AM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Mar 9, 2012, at 11:17 AM, Charles wrote: On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote: From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? Actually, no. To figure this out, somewhere along the line you've got to know where the last day of this month / first day of next month boundary lies, so I don't see how you can ever find the number of days in a month without bringing the start of next month into it somehow. (Even if it's implicitly be getting someone else's clever code to figure out 'last day of this month'!) Well no, I don't need to know the first day of next month to know the last day of this month. That's like saying I need to know who is going to stand at the 'end of the line' NEXT before I can tell who is standing at the 'end of the' line NOW. The number of days in each month is fixed, except for february. If that's what you want, why don't make a table of the number of days in each month, and check for the special case of leap year. No offense, but that's not the point. A look-up table would work, but why when there are all sorts of built-in functions that will? You just said yourself that I don't need to know the first day of next month to know the last day of this month, and AFAIK there is no such function in PHP to get the number of days without accessing the last second in the month. Besides, showing how it is done is part of education. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: [PHP] Function mktime() documentation question
And again to the list, since for some reason Reply-to-all did not do as intended this time. -- Forwarded message -- From: Andrew Ballard aball...@gmail.com Date: Fri, Mar 9, 2012 at 12:53 PM Subject: Re: [PHP] Function mktime() documentation question To: Tedd Sperling tedd.sperl...@gmail.com On Fri, Mar 9, 2012 at 12:07 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: [snip] I am just looking for one that is easy to explain to students. Cheers, tedd tedd, Since you are teaching this to students, I would recommend sticking with the internal date functions and avoiding any solution that includes adding or subtracting multiples of the magic number 86400.* Many such solutions fail to take into consideration Daylight Saving Time and are therefore guaranteed to be wrong at least twice a year (if not several months out of the year). Sure, you can write your code to handle the differences correctly, but since the rules governing the time shift are mostly arbitrary and differ across time zones the world over, it seems safer to me to rely on the internal functions when working with dates. Andrew * Even if the internal functions base their calculations on the number of seconds per day, they have at least already handled all the varied time zones and DST rules and been tested in environments all over the world. When those rules change, the internal functions will be adjusted to reflect the changes and should be much more reliable than thousands of instances of multiple strategies that get copied and pasted into projects. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Sat, Mar 10, 2012 at 12:52 AM, Charles peac...@gmail.com wrote: On Sat, Mar 10, 2012 at 12:07 AM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Mar 9, 2012, at 11:17 AM, Charles wrote: On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote: From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? Actually, no. To figure this out, somewhere along the line you've got to know where the last day of this month / first day of next month boundary lies, so I don't see how you can ever find the number of days in a month without bringing the start of next month into it somehow. (Even if it's implicitly be getting someone else's clever code to figure out 'last day of this month'!) Well no, I don't need to know the first day of next month to know the last day of this month. That's like saying I need to know who is going to stand at the 'end of the line' NEXT before I can tell who is standing at the 'end of the' line NOW. The number of days in each month is fixed, except for february. If that's what you want, why don't make a table of the number of days in each month, and check for the special case of leap year. No offense, but that's not the point. A look-up table would work, but why when there are all sorts of built-in functions that will? You just said yourself that I don't need to know the first day of next month to know the last day of this month, and AFAIK there is no such function in PHP to get the number of days without accessing the last second in the month. Besides, showing how it is done is part of education. Unless, of course you install the calendar extension, of which it will provides just the required function http://php.net/manual/en/function.cal-days-in-month.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
Charles peac...@gmail.com wrote: On Sat, Mar 10, 2012 at 12:52 AM, Charles peac...@gmail.com wrote: On Sat, Mar 10, 2012 at 12:07 AM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Mar 9, 2012, at 11:17 AM, Charles wrote: On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling tedd.sperl...@gmail.com wrote: On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote: From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? Actually, no. To figure this out, somewhere along the line you've got to know where the last day of this month / first day of next month boundary lies, so I don't see how you can ever find the number of days in a month without bringing the start of next month into it somehow. (Even if it's implicitly be getting someone else's clever code to figure out 'last day of this month'!) Well no, I don't need to know the first day of next month to know the last day of this month. That's like saying I need to know who is going to stand at the 'end of the line' NEXT before I can tell who is standing at the 'end of the' line NOW. The number of days in each month is fixed, except for february. If that's what you want, why don't make a table of the number of days in each month, and check for the special case of leap year. No offense, but that's not the point. A look-up table would work, but why when there are all sorts of built-in functions that will? You just said yourself that I don't need to know the first day of next month to know the last day of this month, and AFAIK there is no such function in PHP to get the number of days without accessing the last second in the month. Besides, showing how it is done is part of education. Unless, of course you install the calendar extension, of which it will provides just the required function http://php.net/manual/en/function.cal-days-in-month.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php What about just doing this: intval(date(t)); And you can pass in an argument to date() if you need a specific month. Thanks, Ash http://ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Sat, Mar 10, 2012 at 12:57 AM, Charles peac...@gmail.com wrote:
On Sat, Mar 10, 2012 at 12:52 AM, Charles peac...@gmail.com wrote:
On Sat, Mar 10, 2012 at 12:07 AM, Tedd Sperling tedd.sperl...@gmail.com
wrote:
On Mar 9, 2012, at 11:17 AM, Charles wrote:
On Fri, Mar 9, 2012 at 10:58 PM, Tedd Sperling tedd.sperl...@gmail.com
wrote:
On Mar 9, 2012, at 5:37 AM, Ford, Mike wrote:
From: Tedd Sperling [mailto:tedd.sperl...@gmail.com]
But why does anyone have to use the next month to figure out how
many days there are are in this month? Do you see my point?
Actually, no. To figure this out, somewhere along the line you've
got to know where the last day of this month / first day of next
month boundary lies, so I don't see how you can ever find the number
of days in a month without bringing the start of next month into it
somehow. (Even if it's implicitly be getting someone else's clever
code to figure out 'last day of this month'!)
Well no, I don't need to know the first day of next month to know the
last day of this month. That's like saying I need to know who is going
to stand at the 'end of the line' NEXT before I can tell who is standing
at the 'end of the' line NOW.
The number of days in each month is fixed, except for february. If
that's what you want, why don't make a table of the number of days in
each month, and check for the special case of leap year.
No offense, but that's not the point. A look-up table would work, but why
when there are all sorts of built-in functions that will?
You just said yourself that I don't need to know the first day of
next month to know the last day of this month, and AFAIK there is no
such function in PHP to get the number of days
without accessing the last second in the month. Besides, showing how
it is done is part of education.
Unless, of course you install the calendar extension, of which it
will provides just the required function
http://php.net/manual/en/function.cal-days-in-month.php
Okay, scratch that, the standard function works fine
$number_of_days = idate('t', strtotime($year.'-'.$month));
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Mar 9, 2012, at 12:52 PM, Charles wrote: On Sat, Mar 10, 2012 at 12:07 AM, Tedd Sperling tedd.sperl...@gmail.com wrote: Well no, I don't need to know the first day of next month to know the last day of this month. That's like saying I need to know who is going to stand at the 'end of the line' NEXT before I can tell who is standing at the 'end of the' line NOW. You just said yourself that I don't need to know the first day of next month to know the last day of this month, and AFAIK there is no such function in PHP to get the number of days without accessing the last second in the month. Besides, showing how it is done is part of education. Arrggg. When I said I, I meant I and not a php function. Sometimes the point is never made. tedd _ tedd.sperl...@gmail.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Mar 7, 2012, at 4:28 PM, Daniel Brown wrote: On Wed, Mar 7, 2012 at 15:03, Tedd Sperling tedd.sperl...@gmail.com wrote: Hi gang: I am using the getdate(mktime()) functions to get month data (i.e., name of month, first weekday, last day, number of days). To get the number of days for a specific month, I use: // $current_month is the month under question $next_month = $current_month + 1; $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year)); $days_in_current_month = $what_date['mday']; That works for me! However, if you read the documentation, namely: http://php.net/manual/en/function.mktime.php It states: --- quote day The number of the day relative to the end of the previous month. Values 1 to 28, 29, 30 or 31 (depending upon the month) reference the normal days in the relevant month. Values less than 1 (including negative values) reference the days in the previous month, so 0 is the last day of the previous month, -1 is the day before that, etc. Values greater than the number of days in the relevant month reference the appropriate day in the following month(s). --- un-quote From my code, the number of days in a month can be found by using 0 as the first index of the next month -- not the last day of the previous month. I fail to follow. Your code is looking ahead to next month (April), then using the 0 day, which means it's getting the last day (31) of the current month (March). There's no such thing as a 0 April, hence anything less than one should count backward. -- /Daniel P. Brown Daniel: Yes, it uses next month to figure out this month -- that's my point. See my reply to Mike Ford. Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Mar 8, 2012, at 11:20 AM, Ford, Mike wrote: -Original Message- From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] From my code, the number of days in a month can be found by using 0 as the first index of the next month -- not the last day of the previous month. Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. QED. I think it's possible you may be being confuzled by the number of nexts and previouses floating around. Your mktime call is asking for the 0th day of next month, i.e. the last day of the previous month of next month, i.e. the last day of the current month. Which is exactly what you say works. I think. :) However, I agree that the description is not very well worded - saying that days in the requested month are relative to the previous month is very odd indeed if you ask me -- if they must be relative to anything, why not the beginning of the relevant month? Actually, with a bit more thought, I think I'd rewrite it something like this: The day number relative to the given month. Day numbers 1 to 28, 29, 30 or 31 (depending on the month) refer to the normal days in the month. Numbers less than 1 refer to days in the previous month, so 0 is the last day of the preceding month, -1 the day before that, etc. Numbers greater than the actual number of days in the month refer to days in the following month(s). Mike: Very well put. You say: Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. That IS exactly what I am saying. But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? It would have been better if one could use: $what_date = getdate(mktime(0, 0, 0, $this_month, 0, $year)); $days_in_this_month = $what_date['nday']; // note an additional key for getdate() But instead, we have to use: $next_month = $this_month +1; $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year)); $days_in_this_month = $what_date['mday']; Additionally, there's a perception problem. You say that 0 of the next month *is* the last day of the current month -- as such, apparently months overlap in your (and Dan's) explanation. Well... I agree with both of you, but my objection is having to increase the month value by one to get the number of days in the current month. That's all I was saying. Side-point: I find it interesting that getdate() has all sorts of neat descriptions for the current month (such as, what weekday a numbered day is), but lacks how many days are in the month. Doesn't that seem odd? Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Mar 8, 2012 6:14 PM, Tedd Sperling tedd.sperl...@gmail.com wrote:
On Mar 8, 2012, at 11:20 AM, Ford, Mike wrote:
-Original Message-
From: Tedd Sperling [mailto:tedd.sperl...@gmail.com]
From my code, the number of days in a month can be found by using 0
as the first index of the next month -- not the last day of the
previous month.
Huh? The 0th day of next month *is* the last day of the current month,
which gives you the number of days in the current month. QED.
I think it's possible you may be being confuzled by the number of
nexts and previouses floating around. Your mktime call is asking for
the 0th day of next month, i.e. the last day of the previous month of
next month, i.e. the last day of the current month. Which is exactly
what you say works. I think. :)
However, I agree that the description is not very well worded - saying
that days in the requested month are relative to the previous month is
very odd indeed if you ask me -- if they must be relative to anything,
why not the beginning of the relevant month? Actually, with a bit more
thought, I think I'd rewrite it something like this:
The day number relative to the given month. Day numbers 1 to 28, 29,
30 or 31 (depending on the month) refer to the normal days in the
month. Numbers less than 1 refer to days in the previous month, so 0
is the last day of the preceding month, -1 the day before that, etc.
Numbers greater than the actual number of days in the month refer to
days in the following month(s).
Mike:
Very well put.
You say:
Huh? The 0th day of next month *is* the last day of the current month,
which gives you the number of days in the current month.
That IS exactly what I am saying.
But why does anyone have to use the next month to figure out how many
days there are are in this month? Do you see my point?
It would have been better if one could use:
$what_date = getdate(mktime(0, 0, 0, $this_month, 0, $year));
$days_in_this_month = $what_date['nday']; // note an additional key for
getdate()
But instead, we have to use:
$next_month = $this_month +1;
$what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year));
$days_in_this_month = $what_date['mday'];
Additionally, there's a perception problem. You say that 0 of the next
month *is* the last day of the current month -- as such, apparently months
overlap in your (and Dan's) explanation. Well... I agree with both of you,
but my objection is having to increase the month value by one to get the
number of days in the current month.
That's all I was saying.
Side-point: I find it interesting that getdate() has all sorts of neat
descriptions for the current month (such as, what weekday a numbered day
is), but lacks how many days are in the month. Doesn't that seem odd?
Oh, I see what you're saying now. Well, using getdate(), how else would
you think to pass the parameter to get the last day other than using the
current month and the last day (which would then obviously be overkill, of
course).
All of this aside, though, you may instead want to use something along the
lines of date('d',strtotime('last day of this month')); in tandem with your
date formatting.
Re: [PHP] Function mktime() documentation question
On 03/08/2012 03:14 PM, Tedd Sperling wrote: On Mar 8, 2012, at 11:20 AM, Ford, Mike wrote: -Original Message- From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] From my code, the number of days in a month can be found by using 0 as the first index of the next month -- not the last day of the previous month. Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. QED. I think it's possible you may be being confuzled by the number of nexts and previouses floating around. Your mktime call is asking for the 0th day of next month, i.e. the last day of the previous month of next month, i.e. the last day of the current month. Which is exactly what you say works. I think. :) However, I agree that the description is not very well worded - saying that days in the requested month are relative to the previous month is very odd indeed if you ask me -- if they must be relative to anything, why not the beginning of the relevant month? Actually, with a bit more thought, I think I'd rewrite it something like this: The day number relative to the given month. Day numbers 1 to 28, 29, 30 or 31 (depending on the month) refer to the normal days in the month. Numbers less than 1 refer to days in the previous month, so 0 is the last day of the preceding month, -1 the day before that, etc. Numbers greater than the actual number of days in the month refer to days in the following month(s). Mike: Very well put. You say: Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. That IS exactly what I am saying. But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? It would have been better if one could use: $what_date = getdate(mktime(0, 0, 0, $this_month, 0, $year)); $days_in_this_month = $what_date['nday']; // note an additional key for getdate() But instead, we have to use: $next_month = $this_month +1; $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year)); $days_in_this_month = $what_date['mday']; Additionally, there's a perception problem. You say that 0 of the next month *is* the last day of the current month -- as such, apparently months overlap in your (and Dan's) explanation. Well... I agree with both of you, but my objection is having to increase the month value by one to get the number of days in the current month. That's all I was saying. Side-point: I find it interesting that getdate() has all sorts of neat descriptions for the current month (such as, what weekday a numbered day is), but lacks how many days are in the month. Doesn't that seem odd? Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com I am surprised that nobody has come up with this one yet. $what_date = getdate(mktime(0, 0, 0, $this_month, 35, $year)); $days_in_this_month = 35 - $what_date['mday']; -- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ http://www.bendsource.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On 03/08/2012 04:24 PM, Jim Lucas wrote: On 03/08/2012 03:14 PM, Tedd Sperling wrote: On Mar 8, 2012, at 11:20 AM, Ford, Mike wrote: -Original Message- From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] From my code, the number of days in a month can be found by using 0 as the first index of the next month -- not the last day of the previous month. Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. QED. I think it's possible you may be being confuzled by the number of nexts and previouses floating around. Your mktime call is asking for the 0th day of next month, i.e. the last day of the previous month of next month, i.e. the last day of the current month. Which is exactly what you say works. I think. :) However, I agree that the description is not very well worded - saying that days in the requested month are relative to the previous month is very odd indeed if you ask me -- if they must be relative to anything, why not the beginning of the relevant month? Actually, with a bit more thought, I think I'd rewrite it something like this: The day number relative to the given month. Day numbers 1 to 28, 29, 30 or 31 (depending on the month) refer to the normal days in the month. Numbers less than 1 refer to days in the previous month, so 0 is the last day of the preceding month, -1 the day before that, etc. Numbers greater than the actual number of days in the month refer to days in the following month(s). Mike: Very well put. You say: Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. That IS exactly what I am saying. But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? It would have been better if one could use: $what_date = getdate(mktime(0, 0, 0, $this_month, 0, $year)); $days_in_this_month = $what_date['nday']; // note an additional key for getdate() But instead, we have to use: $next_month = $this_month +1; $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year)); $days_in_this_month = $what_date['mday']; Additionally, there's a perception problem. You say that 0 of the next month *is* the last day of the current month -- as such, apparently months overlap in your (and Dan's) explanation. Well... I agree with both of you, but my objection is having to increase the month value by one to get the number of days in the current month. That's all I was saying. Side-point: I find it interesting that getdate() has all sorts of neat descriptions for the current month (such as, what weekday a numbered day is), but lacks how many days are in the month. Doesn't that seem odd? Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com I am surprised that nobody has come up with this one yet. $what_date = getdate(mktime(0, 0, 0, $this_month, 35, $year)); $days_in_this_month = 35 - $what_date['mday']; Even a one liner... $what_date = getdate(mktime(0,0,0,$this_month,35,$year)-(35 * 86400)); -- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ http://www.bendsource.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On 03/08/2012 04:31 PM, Jim Lucas wrote: On 03/08/2012 04:24 PM, Jim Lucas wrote: On 03/08/2012 03:14 PM, Tedd Sperling wrote: On Mar 8, 2012, at 11:20 AM, Ford, Mike wrote: -Original Message- From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] From my code, the number of days in a month can be found by using 0 as the first index of the next month -- not the last day of the previous month. Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. QED. I think it's possible you may be being confuzled by the number of nexts and previouses floating around. Your mktime call is asking for the 0th day of next month, i.e. the last day of the previous month of next month, i.e. the last day of the current month. Which is exactly what you say works. I think. :) However, I agree that the description is not very well worded - saying that days in the requested month are relative to the previous month is very odd indeed if you ask me -- if they must be relative to anything, why not the beginning of the relevant month? Actually, with a bit more thought, I think I'd rewrite it something like this: The day number relative to the given month. Day numbers 1 to 28, 29, 30 or 31 (depending on the month) refer to the normal days in the month. Numbers less than 1 refer to days in the previous month, so 0 is the last day of the preceding month, -1 the day before that, etc. Numbers greater than the actual number of days in the month refer to days in the following month(s). Mike: Very well put. You say: Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. That IS exactly what I am saying. But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? It would have been better if one could use: $what_date = getdate(mktime(0, 0, 0, $this_month, 0, $year)); $days_in_this_month = $what_date['nday']; // note an additional key for getdate() But instead, we have to use: $next_month = $this_month +1; $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year)); $days_in_this_month = $what_date['mday']; Additionally, there's a perception problem. You say that 0 of the next month *is* the last day of the current month -- as such, apparently months overlap in your (and Dan's) explanation. Well... I agree with both of you, but my objection is having to increase the month value by one to get the number of days in the current month. That's all I was saying. Side-point: I find it interesting that getdate() has all sorts of neat descriptions for the current month (such as, what weekday a numbered day is), but lacks how many days are in the month. Doesn't that seem odd? Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com I am surprised that nobody has come up with this one yet. $what_date = getdate(mktime(0, 0, 0, $this_month, 35, $year)); $days_in_this_month = 35 - $what_date['mday']; Even a one liner... $what_date = getdate(mktime(0,0,0,$this_month,35,$year)-(35 * 86400)); Sorry, had my math backwards... $what_date = getdate((35 * 86400)-mktime(0,0,0,$this_month,35,$year)); -- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ http://www.bendsource.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On 03/08/2012 04:44 PM, Jim Lucas wrote: On 03/08/2012 04:31 PM, Jim Lucas wrote: On 03/08/2012 04:24 PM, Jim Lucas wrote: On 03/08/2012 03:14 PM, Tedd Sperling wrote: On Mar 8, 2012, at 11:20 AM, Ford, Mike wrote: -Original Message- From: Tedd Sperling [mailto:tedd.sperl...@gmail.com] From my code, the number of days in a month can be found by using 0 as the first index of the next month -- not the last day of the previous month. Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. QED. I think it's possible you may be being confuzled by the number of nexts and previouses floating around. Your mktime call is asking for the 0th day of next month, i.e. the last day of the previous month of next month, i.e. the last day of the current month. Which is exactly what you say works. I think. :) However, I agree that the description is not very well worded - saying that days in the requested month are relative to the previous month is very odd indeed if you ask me -- if they must be relative to anything, why not the beginning of the relevant month? Actually, with a bit more thought, I think I'd rewrite it something like this: The day number relative to the given month. Day numbers 1 to 28, 29, 30 or 31 (depending on the month) refer to the normal days in the month. Numbers less than 1 refer to days in the previous month, so 0 is the last day of the preceding month, -1 the day before that, etc. Numbers greater than the actual number of days in the month refer to days in the following month(s). Mike: Very well put. You say: Huh? The 0th day of next month *is* the last day of the current month, which gives you the number of days in the current month. That IS exactly what I am saying. But why does anyone have to use the next month to figure out how many days there are are in this month? Do you see my point? It would have been better if one could use: $what_date = getdate(mktime(0, 0, 0, $this_month, 0, $year)); $days_in_this_month = $what_date['nday']; // note an additional key for getdate() But instead, we have to use: $next_month = $this_month +1; $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year)); $days_in_this_month = $what_date['mday']; Additionally, there's a perception problem. You say that 0 of the next month *is* the last day of the current month -- as such, apparently months overlap in your (and Dan's) explanation. Well... I agree with both of you, but my objection is having to increase the month value by one to get the number of days in the current month. That's all I was saying. Side-point: I find it interesting that getdate() has all sorts of neat descriptions for the current month (such as, what weekday a numbered day is), but lacks how many days are in the month. Doesn't that seem odd? Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com I am surprised that nobody has come up with this one yet. $what_date = getdate(mktime(0, 0, 0, $this_month, 35, $year)); $days_in_this_month = 35 - $what_date['mday']; Even a one liner... $what_date = getdate(mktime(0,0,0,$this_month,35,$year)-(35 * 86400)); Sorry, had my math backwards... $what_date = getdate((35 * 86400)-mktime(0,0,0,$this_month,35,$year)); Spoke too soon. Since you have to know the output of getdate() to calculate the minus figure... I guess that won't work. Use the first one that I suggested. -- Jim Lucas http://www.cmsws.com/ http://www.cmsws.com/examples/ http://www.bendsource.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Mar 8, 2012, at 6:53 PM, Daniel Brown wrote:
On Mar 8, 2012 6:14 PM, Tedd Sperling tedd.sperl...@gmail.com wrote:
Side-point: I find it interesting that getdate() has all sorts of neat
descriptions for the current month (such as, what weekday a numbered day
is), but lacks how many days are in the month. Doesn't that seem odd?
Oh, I see what you're saying now. Well, using getdate(), how else would you
think to pass the parameter to get the last day other than using the current
month and the last day (which would then obviously be overkill, of course).
Well.. you could use any number that exceeds 31 -- or -- as I would have
suggested if it had been up to me, zero day would provide the number of days in
*that* month rather than the number of days in the previous month, which was
the point of my post.
All of this aside, though, you may instead want to use something along the
lines of date('d',strtotime('last day of this month')); in tandem with your
date formatting.
That's a good idea, but
date('d',strtotime('last day of this month'));
gives me the number of days in *this* month, but not the next, or previous,
month.
I need the result to be whatever date was selected -- something like:
$number_days = date('d',strtotime('last day of April, 2014'));
But that doesn't work.
You see, I need something that makes sense to students. The idea that you have
to use the zero day (whatever that is) of the next month to see how many days
there are in this month is strange and confusing -- again my point.
Thus far, the following looks better than what I came up with::
$what_date = getdate(mktime(0, 0, 0, $mon, 32, $year));
$days_in_month = 32 - $what_date['mday'];
But it's still strange.
I was using:
// get the last day of the month
$cont = true;
$tday = 27;
while (($tday = 32) ($cont))
{
$tdate = getdate(mktime(0,0,0,$mon,$tday,$year));
if ($tdate[mon] != $mon)
{
$lastday = $tday - 1;
$cont = false;
}
$tday++;
}
It made sense, but was too long. I figured there should be something better and
easier to explain -- but I'm still looking.
Cheers
tedd
_
tedd.sperl...@gmail.com
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Fri, Mar 9, 2012 at 9:23 AM, Tedd Sperling tedd.sperl...@gmail.com wrote:
On Mar 8, 2012, at 6:53 PM, Daniel Brown wrote:
On Mar 8, 2012 6:14 PM, Tedd Sperling tedd.sperl...@gmail.com wrote:
Side-point: I find it interesting that getdate() has all sorts of neat
descriptions for the current month (such as, what weekday a numbered day
is), but lacks how many days are in the month. Doesn't that seem odd?
Oh, I see what you're saying now. Well, using getdate(), how else would you
think to pass the parameter to get the last day other than using the current
month and the last day (which would then obviously be overkill, of course).
Well.. you could use any number that exceeds 31 -- or -- as I would have
suggested if it had been up to me, zero day would provide the number of days
in *that* month rather than the number of days in the previous month, which
was the point of my post.
All of this aside, though, you may instead want to use something along the
lines of date('d',strtotime('last day of this month')); in tandem with your
date formatting.
That's a good idea, but
date('d',strtotime('last day of this month'));
gives me the number of days in *this* month, but not the next, or previous,
month.
I need the result to be whatever date was selected -- something like:
$number_days = date('d',strtotime('last day of April, 2014'));
But that doesn't work.
You see, I need something that makes sense to students. The idea that you
have to use the zero day (whatever that is) of the next month to see how many
days there are in this month is strange and confusing -- again my point.
Thus far, the following looks better than what I came up with::
$what_date = getdate(mktime(0, 0, 0, $mon, 32, $year));
$days_in_month = 32 - $what_date['mday'];
But it's still strange.
I was using:
// get the last day of the month
$cont = true;
$tday = 27;
while (($tday = 32) ($cont))
{
$tdate = getdate(mktime(0,0,0,$mon,$tday,$year));
if ($tdate[mon] != $mon)
{
$lastday = $tday - 1;
$cont = false;
}
$tday++;
}
It made sense, but was too long. I figured there should be something better
and easier to explain -- but I'm still looking.
function count_days($month, $year) { return (mktime(0, 0, 0, $month+1,
1, $year) - mktime(0, 0, 0, $month, 1, $year))/86400; }
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Function mktime() documentation question
Hi gang: I am using the getdate(mktime()) functions to get month data (i.e., name of month, first weekday, last day, number of days). To get the number of days for a specific month, I use: // $current_month is the month under question $next_month = $current_month + 1; $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year)); $days_in_current_month = $what_date['mday']; That works for me! However, if you read the documentation, namely: http://php.net/manual/en/function.mktime.php It states: --- quote day The number of the day relative to the end of the previous month. Values 1 to 28, 29, 30 or 31 (depending upon the month) reference the normal days in the relevant month. Values less than 1 (including negative values) reference the days in the previous month, so 0 is the last day of the previous month, -1 is the day before that, etc. Values greater than the number of days in the relevant month reference the appropriate day in the following month(s). --- un-quote From my code, the number of days in a month can be found by using 0 as the first index of the next month -- not the last day of the previous month. As such, I would re-write the relevant portion of the paragraph to be: day The number of the day relative to the end of the previous month. Values 1 to 28, 29, 30 or 31 (depending upon the month) reference the normal days in the relevant month. Values less than 0 reference the days in the previous month. For example, -1 is the day before the first day of the relevant month. The value 0 is the zero index of the next month, which is also equal to the last day of the relevant month. Values greater than zero are the number of days in the relevant month reference the appropriate day in the following month(s). What say you? Cheers, tedd _ tedd.sperl...@gmail.com http://sperling.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Function mktime() documentation question
Tedd,
This area was always a little grey to me.
I have used -1 to obtain the previous months for some time now.
0 always indicated the beginning index of the current month but the
explanation never seemed to fit the bill.
Having worked extensively in time manipulation in many of the development
projects I have come up with a rule of thumb.
$this_month = date('Y-m-d 00:00:00',mktime(0,0,0,date('m'),1,date('Y')));
$previous_month = date('Y-m-d
00:00:00',mktime(0,0,0,date('m')-1,1,date('Y')));
$next_month = date('Y-m-d 00:00:00',mktime(0,0,0,date('m')+1,1,date('Y')));
To get the days of any given month or just about anything you need to just
use the strtotime
$days_in_month = date('j',strtotime($this_month));
-Original Message-
From: Tedd Sperling [mailto:tedd.sperl...@gmail.com]
Sent: Wednesday, March 07, 2012 3:04 PM
To: PHP-General List
Subject: [PHP] Function mktime() documentation question
Hi gang:
I am using the getdate(mktime()) functions to get month data (i.e., name of
month, first weekday, last day, number of days).
To get the number of days for a specific month, I use:
// $current_month is the month under question
$next_month = $current_month + 1;
$what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year));
$days_in_current_month = $what_date['mday'];
That works for me!
However, if you read the documentation, namely:
http://php.net/manual/en/function.mktime.php
It states:
--- quote
day
The number of the day relative to the end of the previous month. Values 1 to
28, 29, 30 or 31 (depending upon the month) reference the normal days in the
relevant month. Values less than 1 (including negative values) reference the
days in the previous month, so 0 is the last day of the previous month, -1
is the day before that, etc. Values greater than the number of days in the
relevant month reference the appropriate day in the following month(s).
--- un-quote
From my code, the number of days in a month can be found by using 0 as the
first index of the next month -- not the last day of the previous month.
As such, I would re-write the relevant portion of the paragraph to be:
day
The number of the day relative to the end of the previous month. Values 1 to
28, 29, 30 or 31 (depending upon the month) reference the normal days in the
relevant month. Values less than 0 reference the days in the previous month.
For example, -1 is the day before the first day of the relevant month. The
value 0 is the zero index of the next month, which is also equal to the last
day of the relevant month. Values greater than zero are the number of days
in the relevant month reference the appropriate day in the following
month(s).
What say you?
Cheers,
tedd
_
tedd.sperl...@gmail.com
http://sperling.com
--
PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Wed, Mar 7, 2012 at 15:03, Tedd Sperling tedd.sperl...@gmail.com wrote: Hi gang: I am using the getdate(mktime()) functions to get month data (i.e., name of month, first weekday, last day, number of days). To get the number of days for a specific month, I use: // $current_month is the month under question $next_month = $current_month + 1; $what_date = getdate(mktime(0, 0, 0, $next_month, 0, $year)); $days_in_current_month = $what_date['mday']; That works for me! However, if you read the documentation, namely: http://php.net/manual/en/function.mktime.php It states: --- quote day The number of the day relative to the end of the previous month. Values 1 to 28, 29, 30 or 31 (depending upon the month) reference the normal days in the relevant month. Values less than 1 (including negative values) reference the days in the previous month, so 0 is the last day of the previous month, -1 is the day before that, etc. Values greater than the number of days in the relevant month reference the appropriate day in the following month(s). --- un-quote From my code, the number of days in a month can be found by using 0 as the first index of the next month -- not the last day of the previous month. I fail to follow. Your code is looking ahead to next month (April), then using the 0 day, which means it's getting the last day (31) of the current month (March). There's no such thing as a 0 April, hence anything less than one should count backward. -- /Daniel P. Brown Network Infrastructure Manager http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
To get the number of days for a specific month, I use: // $current_month is the month under question $next_month = $current_month + 1; I use this $next_month = $current_month + 1; $next_month_1= mktime(0, 0, 0, $next_month, 1, date(Y) ); $current_month_1= mktime(0, 0, 0, $current_month, 1, date(Y) ); $mdays = ($current_month_1 - $next_month_1)/(3600*24); It's much more easier if you use DateTime and DateInterval class -- Shiplu.Mokadd.im ImgSign.com | A dynamic signature machine Innovation distinguishes between follower and leader
Re: [PHP] Function mktime() documentation question
Hi, All
To bring a work-around into this discussion I myself would not see it
as a good way to do it like that - even if the documentation provides
some information around that.
Here's what I have done in all new projects I worked with time-calculation:
@Tedd: Lets pick up your first example and work with the
DateTime-Object instead:
$date = new DateTime($year . '-' . $current_month . '-1');
$date-add( new DateInterval( 'P1M' ) ); // Add a period of 1 month to
the date-instance (haven't tried that with the 30th of Jan ... would
be kind-of interesting)
$days_in_current_month = $date-format('j'); // Get the date of the month
As this does not solve the problem (as we still should update the
documentation or the code if it does not match) it's not a solution,
but a suggestion to coding-style at all.
It seems a bit cleaner to me as you don't have to worry about the 13th
month, time-zones or other things that can be difficult to calculate
yourself.
Bye
Simon
2012/3/8 shiplu shiplu@gmail.com:
To get the number of days for a specific month, I use:
// $current_month is the month under question
$next_month = $current_month + 1;
I use this
$next_month = $current_month + 1;
$next_month_1 = mktime(0, 0, 0, $next_month, 1, date(Y) );
$current_month_1= mktime(0, 0, 0, $current_month, 1, date(Y) );
$mdays = ($current_month_1 - $next_month_1)/(3600*24);
It's much more easier if you use DateTime and DateInterval class
--
Shiplu.Mokadd.im
ImgSign.com | A dynamic signature machine
Innovation distinguishes between follower and leader
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function mktime() documentation question
On Thu, Mar 8, 2012 at 7:01 AM, Simon Schick
simonsimc...@googlemail.com wrote:
$date = new DateTime($year . '-' . $current_month . '-1');
$date-add( new DateInterval( 'P1M' ) ); // Add a period of 1 month to
the date-instance (haven't tried that with the 30th of Jan ... would
be kind-of interesting)
$days_in_current_month = $date-format('j'); // Get the date of the month
I think you'd need to subtract it with 1 day
date_create(date('Y-m'))-add(new DateInterval('P1M'))-sub(new
DateInterval('P1D'))-format('d');
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Function links on error and warningmessages
Hi guys, I was wondering some time ago, why the links which are shown on error or warning (E_WARNING etc.) show relative links to an usually non-existing file. Wouldn't it be much more useful if all errors are linking to the function description on php.net? So, if I get an error with file_exists, for example, it links on myCurrentDir/function.file-exists.php. Wouldn't it be nice if it links to http://php.net/file_exists? Regards, Flo
RE: [PHP] Function links on error and warningmessages
-Original Message- From: Florian Müller [mailto:florip...@hotmail.com] Sent: 03 February 2012 14:36 Hi guys, I was wondering some time ago, why the links which are shown on error or warning (E_WARNING etc.) show relative links to an usually non-existing file. Because you haven't set the docref_root configuration option? (See http://php.net/errorfunc.configuration.php#ini.docref-root). Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Portland PD507, City Campus, Leeds Metropolitan University, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function links on error and warningmessages
On Fri, Feb 3, 2012 at 4:35 PM, Ford, Mike m.f...@leedsmet.ac.uk wrote: -Original Message- From: Florian Müller [mailto:florip...@hotmail.com] Sent: 03 February 2012 14:36 Hi guys, I was wondering some time ago, why the links which are shown on error or warning (E_WARNING etc.) show relative links to an usually non-existing file. Because you haven't set the docref_root configuration option? (See http://php.net/errorfunc.configuration.php#ini.docref-root). Cheers! Mike While that's indeed correct, I wonder why the docref_root isn't set by default (eg. www.php.net)? - Matijn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] function exists in command line but not in browser
Hi all, The problem is imagettfbbox(). jpgraph uses it to create truetype font images. I have a phpinfo() script. The command line output: php i.php | grep Free FreeType Support = enabled FreeType Linkage = with freetype FreeType Version = 2.2.1 But when the script is loaded in the browser, the output has no such FreeType Support! So imagettfbbox() does not exist. Somebody could offer some suggestions?? Thank you veery much. -- With best regards, Shelley Shyan http://phparch.cn
Re: [PHP] function exists in command line but not in browser
On Mon, Jul 19, 2010 at 2:22 PM, Shelley myphpl...@gmail.com wrote: Hi all, The problem is imagettfbbox(). jpgraph uses it to create truetype font images. I have a phpinfo() script. The command line output: php i.php | grep Free FreeType Support = enabled FreeType Linkage = with freetype FreeType Version = 2.2.1 But when the script is loaded in the browser, the output has no such FreeType Support! So imagettfbbox() does not exist. Somebody could offer some suggestions?? Thank you veery much. -- With best regards, Shelley Shyan http://phparch.cn Your set up is using two different INI files for command line and web. In the phpinfo(), see Parsed Configuration File (something similar), its at the top of the page, some four-five lines down. -- Regards, Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function exists in command line but not in browser
On 19 July 2010 10:04, Nilesh Govindarajan li...@itech7.com wrote: On Mon, Jul 19, 2010 at 2:22 PM, Shelley myphpl...@gmail.com wrote: Hi all, The problem is imagettfbbox(). jpgraph uses it to create truetype font images. I have a phpinfo() script. The command line output: php i.php | grep Free FreeType Support = enabled FreeType Linkage = with freetype FreeType Version = 2.2.1 But when the script is loaded in the browser, the output has no such FreeType Support! So imagettfbbox() does not exist. Somebody could offer some suggestions?? Thank you veery much. -- With best regards, Shelley Shyan http://phparch.cn Your set up is using two different INI files for command line and web. In the phpinfo(), see Parsed Configuration File (something similar), its at the top of the page, some four-five lines down. http://docs.php.net/manual/en/configuration.file.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function within a class function
On 21 June 2010 00:45, Rick Pasotto r...@niof.net wrote:
Within a class function I have defined another function for use with the
usort() function. How do I reference it?
When it's not part of a class usort($arr,cmp) works fine but when it's
within a class function I get this error:
PHP Parse error: syntax error, unexpected T_STRING, expecting T_FUNCTION
Is it not in the scope of the class function?
--
Memory is like an orgasm. It's a lot better if you don't have to fake it.
-- Seymour Cray (on virtual memory)
Rick Pasotto r...@niof.net http://www.niof.net
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
?php
class foo {
public $array = array(3,2,1);
private function cmp($a, $b) {
return $a === $b ? 0 : ($a $b ? -1 : 1);
}
public function bar() {
usort($this-array, array($this, 'cmp'));
}
}
$baz = new foo();
$baz-bar();
print_r($baz-array);
or
?php
class foo {
public $array = array(3,2,1);
public function bar() {
usort($this-array, function($a, $b) {
return $a === $b ? 0 : ($a $b ? -1 : 1);
});
}
}
$baz = new foo();
$baz-bar();
print_r($baz-array);
if you have closures available to you.
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE : http://www.experts-exchange.com/M_248814.html
EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] function within a class function
Within a class function I have defined another function for use with the usort() function. How do I reference it? When it's not part of a class usort($arr,cmp) works fine but when it's within a class function I get this error: PHP Parse error: syntax error, unexpected T_STRING, expecting T_FUNCTION Is it not in the scope of the class function? -- Memory is like an orgasm. It's a lot better if you don't have to fake it. -- Seymour Cray (on virtual memory) Rick Pasottor...@niof.nethttp://www.niof.net -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function within a class function
On Sun, Jun 20, 2010 at 08:47:53PM -0400, Brandon Rampersad wrote: $this-usort(); self::usort(); On Sun, Jun 20, 2010 at 7:45 PM, Rick Pasotto r...@niof.net wrote: Within a class function I have defined another function for use with the usort() function. How do I reference it? When it's not part of a class usort($arr,cmp) works fine but when it's within a class function I get this error: PHP Parse error: syntax error, unexpected T_STRING, expecting T_FUNCTION Is it not in the scope of the class function? Forgive my ignorance but I have absolutely no idea what you're trying to tell me. usort() is part of the language so when, why, how does it become an object of some class? -- We have rights, as individuals, to give as much of our own money as we please to charity; but as members of Congress we have no right so to appropriate a dollar of public money. -- David Crockett Rick Pasottor...@niof.nethttp://www.niof.net -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] getaddrinfo() - what is the equivalent php function?
Per Jessen wrote: AFAICT, gethostbyname() only works for ipv4 addresses, so that one is out - dns_get_record seems to be really for dns only, i.e. it does not look at /etc/hosts. Is there a hph function that essentially just calls getaddrinfo() ? Wow, lots of answers to that one. Let me rephrase it then - what is the PHP interface to the system resolver when support for IPv6 is required? Again, gethostbyname() only works for IPv4 and dns_get_record is not a resolver interface, but a DNS interface. (AFAICT). -- Per Jessen, Zürich (14.9°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] getaddrinfo() - what is the equivalent php function?
AFAICT, gethostbyname() only works for ipv4 addresses, so that one is out - dns_get_record seems to be really for dns only, i.e. it does not look at /etc/hosts. Is there a hph function that essentially just calls getaddrinfo() ? -- Per Jessen, Zürich (19.1°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function/class to convert IDN (Puny-Code)?
At 4:51 AM +0200 5/13/10, Michelle Konzack wrote: Hello, while reading RFC3490 (plus 3454/3491/3492) and before I am ongoing to reinvent the wheel here the question: Does someone HAVE or know a function/class which does the IDN conversion toASCII and toUNICODE? Note: The C Source-Code is included in RFC3492 and can more or less easily converted to PHP. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator You might try: http://josefsson.org/idn.php I use: http://mct.verisign-grs.com/index.shtml Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] function/class to convert IDN (Puny-Code)?
Hello, while reading RFC3490 (plus 3454/3491/3492) and before I am ongoing to reinvent the wheel here the question: Does someone HAVE or know a function/class which does the IDN conversion toASCII and toUNICODE? Note: The C Source-Code is included in RFC3492 and can more or less easily converted to PHP. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsyst...@tdnet France itsyst...@tdnet UG (haftungsbeschränkt) Gesch. Michelle Konzack Gesch. Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature
Re: [PHP] function not returning query
On Tue, 2009-11-24 at 23:27 -0800, Allen McCabe wrote:
If I were to loop through my inputs, I could just exclude any
problematic names, eg.:
foreach ($_POST as $var = $val)
{
if ($var != filter.x || $var != filter.y)
{
$var = $val;
}
}
Like that?
On Tue, Nov 24, 2009 at 2:34 AM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
On Tue, 2009-11-24 at 02:11 -0800, Allen McCabe wrote:
I am! Will these extra query variables cause any problems or
should I use standard submit inputs?
Thanks Ashley!
On Tue, Nov 24, 2009 at 1:10 AM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
On Mon, 2009-11-23 at 21:53 -0800, Allen McCabe
wrote:
Okay, suddenly I got it to filter the results, but I
still can't figure out
where this part of the query is coming from, at the end
of the query string
in the URL, I have this filter.x=0filter.y=0.
No where in my form do I have a field named filter.x or
filter.y. I DO
however, have 3 forms (I don't want to mess with AJAX),
my set up looks like
this:
Filter by:
User - [username dropdown v] Order by [database fields
v] Asc/Desc
[Ascend v] - Go
School - [school dropdown v] Order by [database fields
v] Asc/Desc
[Ascend v] - Go
Show - [show dropdown v] Order by [database fields v]
Asc/Desc [Ascend v]
- Go
There are actually two order by fields, but this gives
you the idea. Each of
the three lines is a separate form, each with a unique
name all with a get
method, but all three Go buttons are named filter, I
didn't think to try
changing it until now, but is this perhaps where the
filter.x and filter.y
are coming from? I have never seen this before in a query.
Oh, now the filter that was working spontaneously gives
me the error I have
been getting all along, this is so frustrating.
To those who asked, yes I am connected to the database; I
forgot to mention
that the else part of my if statement works, as long as I
don't try to
filter my results it works.
Here is an example of the URL that my filter function
(via one of the 3
forms) outputs:
http://lpacmarketing.hostzi.com/afy/orders/default.php?filterby=schoolschoolid=36orderby1=order_idasc_desc_order1=Descendorderby2=pmt_recd_dateasc_desc_order2=Descendfilter.x=13filter.y=8filter=Go
On Mon, Nov 23, 2009 at 8:03 PM, Philip Thompson
philthath...@gmail.comwrote:
On Nov 23, 2009, at 6:22 PM, Allen McCabe wrote:
Hi, thanks for reading, I hope you can help:
In my main file for an orders page I have the
following code:
if (isset($_GET['filterby']))
{
$resultOrders = adminFilterQuery();
$numberOfOrders = mysql_num_rows($resultOrders);
}
else
{
$resultOrders = mysql_query(SELECT * FROM
afy_order;) or
die(mysql_error(Could not query the database!));
$numberOfOrders = mysql_num_rows($resultOrders);
}
You reduce this part by one line by putting the
following after the else
statement and removing the other 2:
$numberOfOrders = mysql_num_rows ($resultOrders);
Also, these queries don't need a semi-colon (;) to end
the query. PHP
handles this part. Remove them.
adminFilterQuery() is a custom function that is
supposed to return a
mysql_query, here are the last few lines of this
function:
$query = SELECT * FROM afy_order WHERE school_id =
'{$school}' ORDER BY
{$order_by_param};;
$result = mysql_query($query);
return $result;
l am getting this error
Re: [PHP] function not returning query
On Nov 25, 2009, at 4:32 AM, Ashley Sheridan wrote:
On Tue, 2009-11-24 at 23:27 -0800, Allen McCabe wrote:
If I were to loop through my inputs, I could just exclude any
problematic names, eg.:
foreach ($_POST as $var = $val)
{
if ($var != filter.x || $var != filter.y)
{
$var = $val;
}
}
Like that?
!--snip--
Not really, what if someone else decided they wanted to throw in their
own form field values in the hope of breaking your system? It's much
better to be specifically looking for certain form fields and certain
field values/ranges. For example, if you had some fields that would
filter something by cost, you might have two form fields named 'max' and
'min' which would be ranges for the cost. You should check that these
fields only contain numbers for example before processing them. Any data
coming from the client-side is untrustworthy and should be regarded as
tainted until you can prove otherwise.
Thanks,
Ash
The system Ash is referring to is a whitebox approach. You know what you should
get in, so only accept those values. A simple thing to accomplish what you're
trying to do, Allen, would be to create an array of required/accepted fields...
?php
$acceptable = array('green', 'blue', 'red');
foreach ($_POST as $var = $val) {
if (in_array ($var, $acceptable)) {
// Do whatever here
} else {
// Not acceptable - throw error message or do nothing
}
}
?
Hope that helps.
~Philip
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function not returning query
On Mon, 2009-11-23 at 21:53 -0800, Allen McCabe wrote:
Okay, suddenly I got it to filter the results, but I still can't figure out
where this part of the query is coming from, at the end of the query string
in the URL, I have this filter.x=0filter.y=0.
No where in my form do I have a field named filter.x or filter.y. I DO
however, have 3 forms (I don't want to mess with AJAX), my set up looks like
this:
Filter by:
User - [username dropdown v] Order by [database fields v] Asc/Desc
[Ascend v] - Go
School - [school dropdown v] Order by [database fields v] Asc/Desc
[Ascend v] - Go
Show - [show dropdown v] Order by [database fields v] Asc/Desc [Ascend v]
- Go
There are actually two order by fields, but this gives you the idea. Each of
the three lines is a separate form, each with a unique name all with a get
method, but all three Go buttons are named filter, I didn't think to try
changing it until now, but is this perhaps where the filter.x and filter.y
are coming from? I have never seen this before in a query.
Oh, now the filter that was working spontaneously gives me the error I have
been getting all along, this is so frustrating.
To those who asked, yes I am connected to the database; I forgot to mention
that the else part of my if statement works, as long as I don't try to
filter my results it works.
Here is an example of the URL that my filter function (via one of the 3
forms) outputs:
http://lpacmarketing.hostzi.com/afy/orders/default.php?filterby=schoolschoolid=36orderby1=order_idasc_desc_order1=Descendorderby2=pmt_recd_dateasc_desc_order2=Descendfilter.x=13filter.y=8filter=Go
On Mon, Nov 23, 2009 at 8:03 PM, Philip Thompson
philthath...@gmail.comwrote:
On Nov 23, 2009, at 6:22 PM, Allen McCabe wrote:
Hi, thanks for reading, I hope you can help:
In my main file for an orders page I have the following code:
if (isset($_GET['filterby']))
{
$resultOrders = adminFilterQuery();
$numberOfOrders = mysql_num_rows($resultOrders);
}
else
{
$resultOrders = mysql_query(SELECT * FROM afy_order;) or
die(mysql_error(Could not query the database!));
$numberOfOrders = mysql_num_rows($resultOrders);
}
You reduce this part by one line by putting the following after the else
statement and removing the other 2:
$numberOfOrders = mysql_num_rows ($resultOrders);
Also, these queries don't need a semi-colon (;) to end the query. PHP
handles this part. Remove them.
adminFilterQuery() is a custom function that is supposed to return a
mysql_query, here are the last few lines of this function:
$query = SELECT * FROM afy_order WHERE school_id = '{$school}' ORDER BY
{$order_by_param};;
$result = mysql_query($query);
return $result;
l am getting this error when I try to filter my query using a form in
tandem
with the quey building function:
*Warning*: mysql_num_rows(): supplied argument is not a valid MySQL
result
resource
where the line is the one where I use the mysql_num_rows function.
What am I missing here?
Thanks!
Do you get this warning with both queries? Make sure that your queries are
using a valid mysql connection. You may also consider using a database class
to perform the repetitive tasks so that you really only have to be concerned
with the queries you're writing...?
?php
class database {
public function query ($sql) {
$result = mysql_query ($sql);
if ($result === false) {
die ('Uh oh!');
}
return $result;
}
public function numRows ($result) {
return mysql_num_rows ($result);
}
}
$db = new database();
$result = $db-query('SELECT * FROM afy_order');
$numRows = $db-numRows($result);
?
Of course this is just a simple example, but you get the idea. Hope that
stirs your brain!
~Philip
My guess would be that you're submitting the form using an image button,
which would send the x and y coordinates of the click within the button.
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [PHP] function not returning query
On Tue, 2009-11-24 at 02:11 -0800, Allen McCabe wrote:
I am! Will these extra query variables cause any problems or should I
use standard submit inputs?
Thanks Ashley!
On Tue, Nov 24, 2009 at 1:10 AM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
On Mon, 2009-11-23 at 21:53 -0800, Allen McCabe wrote:
Okay, suddenly I got it to filter the results, but I still can't
figure out
where this part of the query is coming from, at the end of the
query string
in the URL, I have this filter.x=0filter.y=0.
No where in my form do I have a field named filter.x or filter.y. I
DO
however, have 3 forms (I don't want to mess with AJAX), my set up
looks like
this:
Filter by:
User - [username dropdown v] Order by [database fields v] Asc/Desc
[Ascend v] - Go
School - [school dropdown v] Order by [database fields v] Asc/Desc
[Ascend v] - Go
Show - [show dropdown v] Order by [database fields v] Asc/Desc
[Ascend v]
- Go
There are actually two order by fields, but this gives you the
idea. Each of
the three lines is a separate form, each with a unique name all
with a get
method, but all three Go buttons are named filter, I didn't think
to try
changing it until now, but is this perhaps where the filter.x and
filter.y
are coming from? I have never seen this before in a query.
Oh, now the filter that was working spontaneously gives me the
error I have
been getting all along, this is so frustrating.
To those who asked, yes I am connected to the database; I forgot to
mention
that the else part of my if statement works, as long as I don't try
to
filter my results it works.
Here is an example of the URL that my filter function (via one of
the 3
forms) outputs:
http://lpacmarketing.hostzi.com/afy/orders/default.php?filterby=schoolschoolid=36orderby1=order_idasc_desc_order1=Descendorderby2=pmt_recd_dateasc_desc_order2=Descendfilter.x=13filter.y=8filter=Go
On Mon, Nov 23, 2009 at 8:03 PM, Philip Thompson
philthath...@gmail.comwrote:
On Nov 23, 2009, at 6:22 PM, Allen McCabe wrote:
Hi, thanks for reading, I hope you can help:
In my main file for an orders page I have the following code:
if (isset($_GET['filterby']))
{
$resultOrders = adminFilterQuery();
$numberOfOrders = mysql_num_rows($resultOrders);
}
else
{
$resultOrders = mysql_query(SELECT * FROM afy_order;) or
die(mysql_error(Could not query the database!));
$numberOfOrders = mysql_num_rows($resultOrders);
}
You reduce this part by one line by putting the following after
the else
statement and removing the other 2:
$numberOfOrders = mysql_num_rows ($resultOrders);
Also, these queries don't need a semi-colon (;) to end the query.
PHP
handles this part. Remove them.
adminFilterQuery() is a custom function that is supposed to
return a
mysql_query, here are the last few lines of this function:
$query = SELECT * FROM afy_order WHERE school_id = '{$school}'
ORDER BY
{$order_by_param};;
$result = mysql_query($query);
return $result;
l am getting this error when I try to filter my query using a
form in
tandem
with the quey building function:
*Warning*: mysql_num_rows(): supplied argument is not a valid
MySQL
result
resource
where the line is the one where I use the mysql_num_rows
function.
What am I missing here?
Thanks!
Do you get this warning with both queries? Make sure that your
queries are
using a valid mysql connection. You may also consider using a
database class
to perform the repetitive tasks so that you really only have to
be concerned
with the queries you're writing...?
?php
class database {
public function query ($sql) {
$result = mysql_query ($sql);
if ($result === false) {
die ('Uh oh!');
}
return $result;
}
public function numRows ($result) {
return mysql_num_rows ($result);
}
[PHP] function not returning query
Hi, thanks for reading, I hope you can help:
In my main file for an orders page I have the following code:
if (isset($_GET['filterby']))
{
$resultOrders = adminFilterQuery();
$numberOfOrders = mysql_num_rows($resultOrders);
}
else
{
$resultOrders = mysql_query(SELECT * FROM afy_order;) or
die(mysql_error(Could not query the database!));
$numberOfOrders = mysql_num_rows($resultOrders);
}
adminFilterQuery() is a custom function that is supposed to return a
mysql_query, here are the last few lines of this function:
$query = SELECT * FROM afy_order WHERE school_id = '{$school}' ORDER BY
{$order_by_param};;
$result = mysql_query($query);
return $result;
l am getting this error when I try to filter my query using a form in tandem
with the quey building function:
*Warning*: mysql_num_rows(): supplied argument is not a valid MySQL result
resource
where the line is the one where I use the mysql_num_rows function.
What am I missing here?
Thanks!
Re: [PHP] function not returning query
Likely your query failed due to an error.
Try adding an or die(mysql_error()) to the end of your mysql_query
statement to see what that error maybe
Bastien
Sent from my iPod
On Nov 23, 2009, at 7:22 PM, Allen McCabe allenmcc...@gmail.com wrote:
Hi, thanks for reading, I hope you can help:
In my main file for an orders page I have the following code:
if (isset($_GET['filterby']))
{
$resultOrders = adminFilterQuery();
$numberOfOrders = mysql_num_rows($resultOrders);
}
else
{
$resultOrders = mysql_query(SELECT * FROM afy_order;) or
die(mysql_error(Could not query the database!));
$numberOfOrders = mysql_num_rows($resultOrders);
}
adminFilterQuery() is a custom function that is supposed to return a
mysql_query, here are the last few lines of this function:
$query = SELECT * FROM afy_order WHERE school_id = '{$school}'
ORDER BY
{$order_by_param};;
$result = mysql_query($query);
return $result;
l am getting this error when I try to filter my query using a form
in tandem
with the quey building function:
*Warning*: mysql_num_rows(): supplied argument is not a valid MySQL
result
resource
where the line is the one where I use the mysql_num_rows function.
What am I missing here?
Thanks!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function not returning query
On Nov 23, 2009, at 6:22 PM, Allen McCabe wrote:
Hi, thanks for reading, I hope you can help:
In my main file for an orders page I have the following code:
if (isset($_GET['filterby']))
{
$resultOrders = adminFilterQuery();
$numberOfOrders = mysql_num_rows($resultOrders);
}
else
{
$resultOrders = mysql_query(SELECT * FROM afy_order;) or
die(mysql_error(Could not query the database!));
$numberOfOrders = mysql_num_rows($resultOrders);
}
You reduce this part by one line by putting the following after the else
statement and removing the other 2:
$numberOfOrders = mysql_num_rows ($resultOrders);
Also, these queries don't need a semi-colon (;) to end the query. PHP handles
this part. Remove them.
adminFilterQuery() is a custom function that is supposed to return a
mysql_query, here are the last few lines of this function:
$query = SELECT * FROM afy_order WHERE school_id = '{$school}' ORDER BY
{$order_by_param};;
$result = mysql_query($query);
return $result;
l am getting this error when I try to filter my query using a form in tandem
with the quey building function:
*Warning*: mysql_num_rows(): supplied argument is not a valid MySQL result
resource
where the line is the one where I use the mysql_num_rows function.
What am I missing here?
Thanks!
Do you get this warning with both queries? Make sure that your queries are
using a valid mysql connection. You may also consider using a database class to
perform the repetitive tasks so that you really only have to be concerned with
the queries you're writing...?
?php
class database {
public function query ($sql) {
$result = mysql_query ($sql);
if ($result === false) {
die ('Uh oh!');
}
return $result;
}
public function numRows ($result) {
return mysql_num_rows ($result);
}
}
$db = new database();
$result = $db-query('SELECT * FROM afy_order');
$numRows = $db-numRows($result);
?
Of course this is just a simple example, but you get the idea. Hope that stirs
your brain!
~Philip
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] function not returning query
Okay, suddenly I got it to filter the results, but I still can't figure out
where this part of the query is coming from, at the end of the query string
in the URL, I have this filter.x=0filter.y=0.
No where in my form do I have a field named filter.x or filter.y. I DO
however, have 3 forms (I don't want to mess with AJAX), my set up looks like
this:
Filter by:
User - [username dropdown v] Order by [database fields v] Asc/Desc
[Ascend v] - Go
School - [school dropdown v] Order by [database fields v] Asc/Desc
[Ascend v] - Go
Show - [show dropdown v] Order by [database fields v] Asc/Desc [Ascend v]
- Go
There are actually two order by fields, but this gives you the idea. Each of
the three lines is a separate form, each with a unique name all with a get
method, but all three Go buttons are named filter, I didn't think to try
changing it until now, but is this perhaps where the filter.x and filter.y
are coming from? I have never seen this before in a query.
Oh, now the filter that was working spontaneously gives me the error I have
been getting all along, this is so frustrating.
To those who asked, yes I am connected to the database; I forgot to mention
that the else part of my if statement works, as long as I don't try to
filter my results it works.
Here is an example of the URL that my filter function (via one of the 3
forms) outputs:
http://lpacmarketing.hostzi.com/afy/orders/default.php?filterby=schoolschoolid=36orderby1=order_idasc_desc_order1=Descendorderby2=pmt_recd_dateasc_desc_order2=Descendfilter.x=13filter.y=8filter=Go
On Mon, Nov 23, 2009 at 8:03 PM, Philip Thompson philthath...@gmail.comwrote:
On Nov 23, 2009, at 6:22 PM, Allen McCabe wrote:
Hi, thanks for reading, I hope you can help:
In my main file for an orders page I have the following code:
if (isset($_GET['filterby']))
{
$resultOrders = adminFilterQuery();
$numberOfOrders = mysql_num_rows($resultOrders);
}
else
{
$resultOrders = mysql_query(SELECT * FROM afy_order;) or
die(mysql_error(Could not query the database!));
$numberOfOrders = mysql_num_rows($resultOrders);
}
You reduce this part by one line by putting the following after the else
statement and removing the other 2:
$numberOfOrders = mysql_num_rows ($resultOrders);
Also, these queries don't need a semi-colon (;) to end the query. PHP
handles this part. Remove them.
adminFilterQuery() is a custom function that is supposed to return a
mysql_query, here are the last few lines of this function:
$query = SELECT * FROM afy_order WHERE school_id = '{$school}' ORDER BY
{$order_by_param};;
$result = mysql_query($query);
return $result;
l am getting this error when I try to filter my query using a form in
tandem
with the quey building function:
*Warning*: mysql_num_rows(): supplied argument is not a valid MySQL
result
resource
where the line is the one where I use the mysql_num_rows function.
What am I missing here?
Thanks!
Do you get this warning with both queries? Make sure that your queries are
using a valid mysql connection. You may also consider using a database class
to perform the repetitive tasks so that you really only have to be concerned
with the queries you're writing...?
?php
class database {
public function query ($sql) {
$result = mysql_query ($sql);
if ($result === false) {
die ('Uh oh!');
}
return $result;
}
public function numRows ($result) {
return mysql_num_rows ($result);
}
}
$db = new database();
$result = $db-query('SELECT * FROM afy_order');
$numRows = $db-numRows($result);
?
Of course this is just a simple example, but you get the idea. Hope that
stirs your brain!
~Philip
[PHP] Function Not Working...Little help
Hello,
I am trying to get this function working but it gives me a PHP error
(blank page):
function Validate_Page_Nav($LastPage, $ErrorPage) {
$trimmed = str_replace($staffroot, '', $_SERVER['SCRIPT_NAME']);
$resul = $db-query(SELECT * FROM Page_Access WHERE URI =
'$trimmed') or die(failed to get access data);
$page_access = $resul-fetch_assoc();
$URI_access = explode(,, $page_access['User_Level']);
if($_SESSION['Last_Page'] != $LastPage}) {
header(location: {$ErrorPage}?message=Unable to update user
information.);
exit();
}
if(in_array($_SESSION['Staff_level'], $URI_access)) {
echo Access;
exit();
}else{
echo No Access;
//header(location: {$ErrorPage}?message=Unable to update user
information.);
exit();
}
}
Validate_Page_Nav(user_list.php, user_list.php);
There are parts of the code I was trying to debug.
Any help would be appreciated.
Don Wieland
D W D a t a C o n c e p t s
~
d...@dwdataconcepts.com
Direct Line - (949) 305-2771
Integrated data solutions to fit your business needs.
Need assistance in dialing in your FileMaker solution? Check out our
Developer Support Plan at:
http://www.dwdataconcepts.com/DevSup.html
Appointment 1.0v9 - Powerful Appointment Scheduling for FileMaker Pro
9 or higher
http://www.appointment10.com
For a quick overview -
http://www.appointment10.com/Appt10_Promo/Overview.html
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP function unpack
Hi,
I've sent this mail a few days ago, but as this list have a very high
traffic maybe my mail disappear from you inbox.
Any help would be appreciated.
Thanks in advance,
Gabriel.
On Sun, Oct 11, 2009 at 4:42 PM, Gabriel Hahmann
gabriel.hahm...@gmail.com wrote:
Hi,
I'm new to the list and I've search internet and didn't find an answer
to my problem.
I'm converting a perl script to PHP and I've done almost everything.
The only part of the code that I didn't get working on PHP was:
(PERL CODE)
foreach ($b_length,$b_mac,$b_crlf,$b_crlf,$a_body) {
$d_checksum += unpack(%16n*, $_);
}
The idea is to make a 16-bit checksum of all elements
($b_length,$b_mac,$b_crlf,$b_crlf,$a_body).
I'm tried translating the code to:
$arr_checksum = array($b_length,$b_mac,$b_crlf,$b_crlf,$File_Content);
$d_checksum = 0;
foreach($arr_checksum as $check_elem){
$d_check = unpack(n*, $check_elem);
for ($i=0;$i4;$i++){
$d_checksum += $d_check[$i];
}
}
But the result is different. I know that unpack in perl and php are
different, but I cant find a way to translate the format %16n* of perl
to php and generate a 16-bit checksum.
Any help will be appreciated.
[]'s
Gabriel.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP function unpack
Hi,
I'm new to the list and I've search internet and didn't find an answer
to my problem.
I'm converting a perl script to PHP and I've done almost everything.
The only part of the code that I didn't get working on PHP was:
(PERL CODE)
foreach ($b_length,$b_mac,$b_crlf,$b_crlf,$a_body) {
$d_checksum += unpack(%16n*, $_);
}
The idea is to make a 16-bit checksum of all elements
($b_length,$b_mac,$b_crlf,$b_crlf,$a_body).
I'm tried translating the code to:
$arr_checksum = array($b_length,$b_mac,$b_crlf,$b_crlf,$File_Content);
$d_checksum = 0;
foreach($arr_checksum as $check_elem){
$d_check = unpack(n*, $check_elem);
for ($i=0;$i4;$i++){
$d_checksum += $d_check[$i];
}
}
But the result is different. I know that unpack in perl and php are
different, but I cant find a way to translate the format %16n* of perl
to php and generate a 16-bit checksum.
Any help will be appreciated.
[]'s
Gabriel.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Function parameter passed by reference with default value to null
Hi,
I would like to know if I am alone to be shoked by this :
== 8 ==
function foo( $bar = null)
{
}
foo() ; // runs
foo(null) ; // raise an error
== 8 ==
Why the default value to null for a reference is allowed ? Is it a
bug, a feature ?
Thanks !
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Seeking for a position http://lupusmic.org/pro/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function parameter passed by reference with default value to null
2009/7/6 Lupus Michaelis mickael+...@lupusmic.org:
Hi,
I would like to know if I am alone to be shoked by this :
== 8 ==
function foo( $bar = null)
{
}
foo() ; // runs
foo(null) ; // raise an error
== 8 ==
Why the default value to null for a reference is allowed ? Is it a bug, a
feature ?
You appear to be using the definition of null that comes from the
world of C. A null in PHP is not the same as a null in C - it's a real
value (of type null), not the absence of a value. So what you're doing
is the equivalent of passing a literal value, something you can't do
when the function is expecting a reference.
See the manual for more info on the null type: http://php.net/null
-Stuart
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function parameter passed by reference with default value to null
Stuart a écrit : You appear to be using the definition of null that comes from the world of C. I didn't. The point is I'm allowed to set a default value to null for a referenced parameter (what I can do in C for a pointer, so I knew it). I'm happy PHP raises an error on foo(null) ; I'm in trouble when foo() doesn't. The actual question is : why PHP doesn't raise an error ? -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org Seeking for a position http://lupusmic.org/pro/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function parameter passed by reference with default value to null
2009/7/6 Lupus Michaelis mickael+...@lupusmic.org: Stuart a écrit : You appear to be using the definition of null that comes from the world of C. I didn't. The point is I'm allowed to set a default value to null for a referenced parameter (what I can do in C for a pointer, so I knew it). I'm happy PHP raises an error on foo(null) ; I'm in trouble when foo() doesn't. The actual question is : why PHP doesn't raise an error ? The whole point of default arguments is for it to use that argument if none is passed. What makes you think not passing an argument to that function should raise an error? -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function parameter passed by reference with default value to null
Stuart a écrit : The whole point of default arguments is for it to use that argument if none is passed. It is not the point too. What makes you think not passing an argument to that function should raise an error? Maybe because in my example, the provided value is not a valuable value for a reference ? -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org Seeking for a position http://lupusmic.org/pro/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function parameter passed by reference with default value to null
2009/7/6 Lupus Michaelis mickael+...@lupusmic.org:
I'm happy PHP raises an error on foo(null) ;
I'm in trouble when foo() doesn't.
The actual question is : why PHP doesn't raise an error ?
This functionality (default values for passed-by-reference parameters)
was added in PHP5.
The problem is that you can't pass literals by reference (which makes sense):
function f($a) {}
f(45); // error
But default values must be literals (which also makes sense):
function f($a = $_POST) {} // error
So there's some serious impedance mismatch going on there to make both
features to work together. Just think of the default value as
something I can overwrite, eg:
function f($a = 45) { $a = 99; }
So it doesn't really matter if it starts off as 45, 'Hello World' or
null... it's going to get thrown away at the end of the function's
lifetime, anyway.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Function parameter passed by reference with default value to null
2009/7/6 Lupus Michaelis mickael+...@lupusmic.org: David Otton a écrit : So there's some serious impedance mismatch going on there to make both features to work together. Just think of the default value as something I can overwrite, eg: Thanks for this smart explanation. It shines my day. np. On reflection, it seems to me that if they were dead-set on default values for pass-by-reference variables, they should have dropped the restriction on passing literals by reference at the same time, and just thrown away the result as happens with default values. Oh well, it's not my language design. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
