Closed skn3 closed 11 years ago
blitz-research
commented
11 years ago Nice, but can you rename new User/Pass methods to Username/Password?
I could probably live with User, but Pass is just a bit to vague for my liking so may as well fix both.
skn3
commented
11 years ago Ok made the changes.
skn3
commented
11 years ago Done and done. On 30/04/2013 01:43, blitz-research wrote:
Nice, but can you rename new User/Pass methods to Username/Password?
I could probably live with User, but Pass is just a bit to vague for my liking so may as well fix both.
— Reply to this email directly or view it on GitHub https://github.com/blitz-research/monkey/pull/15#issuecomment-17203704.
blitz-research
commented
11 years ago Ok, in the process of adding this.
I made a lot of Url methods properties, 'coz I'm trying to do that more these days. Wont affect existing code.
I removed the 'debug' param from ToString because it used an declared 'seperator' var and I wasn't sure I liked it anyway.
Only one concern left: Path() now leaves out the query/fragment bits right? Wont this break HttpRequest, which uses Path() with GET? Any good ideas for a shorter PathIncludingQueryAndFragment()? Perhaps FullPath()?
Or Path() could include query/fragment and we can come up with something else for 'without'...
skn3
commented
11 years ago Yeah sounds good to me about properties,
One question about that, I have never found someone who has enough understanding of the underneaths of stuff to answer...
Whats the overhead of accessing a property vs accessing a field?
Obviously accessing a property gets piped through a function..which as I would understand would have to dump loads of stuff on the stack in order to facilitate a call and return. Is this something I should be concerning myself with? I try to stay away from properties because of this, so it would be good to get a good answer?
About the FullPath thing.. you could go the standards way and have a "URI", "Request" or "RequestPath" named method?
If you output server variables in php you get one entry which is:
REQUEST_URI /junk/php/info.php?123
Cheers,
Jon
On 02/05/2013 03:31, blitz-research wrote:
Ok, in the process of adding this.
I made a lot of methods properties, 'coz I'm trying to do that more these days.
I removed the 'debug' param from ToString because it used an declared 'seperator' var and I wasn't sure I liked it anyway.
Only one concern left: Path() now leaves out the query/fragment bits right? Wont this break HttpRequest, which uses Path() with GET? Any good ideas for a shorter PathIncludingQueryAndFragment()? Perhaps FullPath()?
Or Path() could include query/fragment and we can come up with something else for 'without'...
— Reply to this email directly or view it on GitHub https://github.com/blitz-research/monkey/pull/15#issuecomment-17317775.
blitz-research
commented
11 years ago Whats the overhead of accessing a property vs accessing a field?
A property is just a get/set method, so replacing gets/sets with properties is 'free', while deciding whether to convert a field to a property or not is pretty much the same as deciding whether to use a getter/setter.
About the FullPath thing.. you could go the standards way and have a "URI", "Request" or "RequestPath" named method?
I thought URIs were a 'superset' of URLs?
Gah, I've never been entirely clear on the difference...think I'll stick with FullPath for now.
On Thu, May 2, 2013 at 9:36 PM, Jonathan notifications@github.com wrote:
Yeah sounds good to me about properties,
One question about that, I have never found someone who has enough understanding of the underneaths of stuff to answer...
Whats the overhead of accessing a property vs accessing a field?
Obviously accessing a property gets piped through a function..which as I would understand would have to dump loads of stuff on the stack in order to facilitate a call and return. Is this something I should be concerning myself with? I try to stay away from properties because of this, so it would be good to get a good answer?
About the FullPath thing.. you could go the standards way and have a "URI", "Request" or "RequestPath" named method?
If you output server variables in php you get one entry which is:
REQUEST_URI /junk/php/info.php?123
Cheers,
Jon
On 02/05/2013 03:31, blitz-research wrote:
Ok, in the process of adding this.
I made a lot of methods properties, 'coz I'm trying to do that more these days.
I removed the 'debug' param from ToString because it used an declared 'seperator' var and I wasn't sure I liked it anyway.
Only one concern left: Path() now leaves out the query/fragment bits right? Wont this break HttpRequest, which uses Path() with GET? Any good ideas for a shorter PathIncludingQueryAndFragment()? Perhaps FullPath()?
Or Path() could include query/fragment and we can come up with something else for 'without'...
— Reply to this email directly or view it on GitHub <https://github.com/blitz-research/monkey/pull/15#issuecomment-17317775 .
— Reply to this email directly or view it on GitHubhttps://github.com/blitz-research/monkey/pull/15#issuecomment-17328691 .
skn3
commented
11 years ago Hah interesting... nice bit of Friday learning going on here! http://ajaxian.com/archives/uri-vs-url-whats-the-difference
So a URI is a name/address for a location/grouping to something non-speciffic and a URL is a location to something specific and tangible.
Doesn't really help for the url object though haha!
FullPath sounds easier :)
On 03/05/2013 02:50, blitz-research wrote:
Whats the overhead of accessing a property vs accessing a field?
A property is just a get/set method, so replacing gets/sets with properties is 'free', while deciding whether to convert a field to a property or not is pretty much the same as deciding whether to use a getter/setter.
About the FullPath thing.. you could go the standards way and have a "URI", "Request" or "RequestPath" named method?
I thought URIs were a 'superset' of URLs?
Gah, I've never been entirely clear on the difference...think I'll stick with FullPath for now.
On Thu, May 2, 2013 at 9:36 PM, Jonathan notifications@github.com wrote:
Yeah sounds good to me about properties,
One question about that, I have never found someone who has enough understanding of the underneaths of stuff to answer...
Whats the overhead of accessing a property vs accessing a field?
Obviously accessing a property gets piped through a function..which as I would understand would have to dump loads of stuff on the stack in order to facilitate a call and return. Is this something I should be concerning myself with? I try to stay away from properties because of this, so it would be good to get a good answer?
About the FullPath thing.. you could go the standards way and have a "URI", "Request" or "RequestPath" named method?
If you output server variables in php you get one entry which is:
REQUEST_URI /junk/php/info.php?123
Cheers,
Jon
On 02/05/2013 03:31, blitz-research wrote:
Ok, in the process of adding this.
I made a lot of methods properties, 'coz I'm trying to do that more these days.
I removed the 'debug' param from ToString because it used an declared 'seperator' var and I wasn't sure I liked it anyway.
Only one concern left: Path() now leaves out the query/fragment bits right? Wont this break HttpRequest, which uses Path() with GET? Any good ideas for a shorter PathIncludingQueryAndFragment()? Perhaps FullPath()?
Or Path() could include query/fragment and we can come up with something else for 'without'...
— Reply to this email directly or view it on GitHub
<https://github.com/blitz-research/monkey/pull/15#issuecomment-17317775 .
— Reply to this email directly or view it on GitHubhttps://github.com/blitz-research/monkey/pull/15#issuecomment-17328691 .
— Reply to this email directly or view it on GitHub https://github.com/blitz-research/monkey/pull/15#issuecomment-17375098.
Hey Mark,
I wrote a url module at the weekend without realising there was now an official url module.. So to return the favour of win8phone tcpstream, here is an improved url module.
Cheers,
Jon