You can intercept that via the __clone(); magic method / forward, found in the Object Cloning part of the PHP Manual. But like I said, it's only a forward, the clone still happens. You can force an unset of this ... but I'm not sure how that would work should our object have references, it's very likely that the memory would leak.
You can intercept that via the __clone(); magic method / forward, found in the Object Cloning part of the PHP Manual. But like I said, it's only a forward, the clone still happens. You can force an unset of this ... but I'm not sure how that would work should our object have references, it's very likely that the memory would leak.
Sorry, I left out one important detail: $b is not an object in the example.
Oh, well, that's a problem!
Yeah... I mean I understand that there can be fatal errors even in robust implementations, but on cloning? Seriously? If we could at least overload / replace the critical language constructs and functions, but the way it is now, we cannot protect script authors from PHP's stricter-than-your-mother-in-law-hammer-of-fatality, unless we offer alternative functions and keep them from using the originals.
<?php
function safe_clone(&$object)
{
if(is_object($object) && is_callable(array($object, '__clone')))
{
return clone $object;
}
throw new InvalidArgumentException('Passed value is not an object or an uncloneable object.');
return NULL;
}
?>
I guess we get to the point where you have to say it ... That's what C++ is for. And like you said, there is pretty much nothing we can do about this, and I'm not willing to provide a safe alternative to every single php function and language construct out there. It's not my job, it's not your job and we can't be held liable for the bad programming of some one else. But I will do my best to make sure it does not take down the whole system, within reason. After all, if you build something to be idiot proof, someone will build a better idiot.
I don't want a plugin crashing the whole system based on a missed semicolon, or comma. That's the point of the checking within the current system. With the current implementation of the plugin files must be named the same as their class names. So something like '-i myfile.php' is not valid in the first place as it's not a valid class name. One system helps the other in this case. We only need to make sure that the file name is also a valid class name, then we include the file.
You're right, working around the issues is not the way to go. We've got some key points figured out, I might just take the time and report them as bugs over at php.net, because frankly, most of the fatals should be recoverable - in CLI at least.
I might code a validation tool anyway, not for JIT validation like isSafeToInclude(), but for module writers to check their modules for robustness (checking for cloneability prior to cloning, illegal use of reserved names, potential memory leaks and whatnot).
Cool idea, but let's get the core nailed down first. You guys will have a lot of information to go over once I upload the first code base.
Well do it already
By the way, while we're kind of on the subject; will we be commenting for any particular documentation generator? I've somewhat adopted a doxygen compatible style, regardless of whether it's actually passed through doxygen or not.
phpDocumentor, because it's used by Zend and it makes some fantastic documentation from a very small amount of information you put into it. None of the codebase is documented in such a way right now. But it just makes sense to me to use this. It's syntax is fantastically easy:
You add comments for parsing by phpDocumentor in the form of documentation blocks, or DocBlocks. You add the extra * to show it's a DocBlock and not a regluar comment on the opening line.
/**
* Here's comment line 1.
* Here's comment line 2.
*/Within a DocBlock you can use various tags to fine-tune the resulting documentation. Tags begin with an @ symbol, you could use the @param tag to give more information about a function's parameter.
/**
* Echo's a line to the console.
*
* @param string The text to send to the console.
*/
function console($line)
{
echo $line . PHP_EOL;
}The var tag is great for giving more information on variables and properties:
/**
* @var int Timeout in seconds for the socket_select function.
*/
public $sleep = NULL;
/**
* @var int Timeout in microseconds for the socket_select function.
*/
public $uSleep = NULL;
We would also use the @package tag. As this lets you group files and classes together under a single package name:
/**
* PHPInSimMod Class.
* @package PHPInSimMod
*/
class PHPInSimMod
{
// Lot's of code.
}Tons more information and examples can be found at http://manual.phpdoc.org/. They eat their own dog food, their code is documented in this ... so it think that's always a good endorsement.
Looks like it's fairly similar to doxygen in how it's used, will check it out
The project on SF needs some cleaning up, but we should probably keep the PHPLFS remains for now.
I don't have my heart set on it or anything, I'll look into doxygen and see if it offers anything more over phpDocumentor.
That's still ripnet's baby. I'm sure he will deprecate the project, and port all of his plugins over when the time is right.
phpDocumentor's documenting blocks are simpler than doxygen's, but I prefer the output of doxygen. It provides more information in a clear structure, the autolinking is way better and it even provides a search (client-side, javascript!). And of course, there are the nice diagrams... Tough call, but I find myself prefering doxygen overall (although it's HTML output is somewhat terrible, markup-wise).
Yep, I definitely vote doxygen!
Yep, I definitely vote doxygen!
We need to go over the license, the documentation engine, and the name.
I've not seen Ripnet in a while, so I don't know what he is up to or if he has seen the PRISM short name yet. But assuming he has picked that name, I've used that to outline most of the built in commands, and it's being used in the source code.
As far as documentation engine, I'll use doxygen, just because it's used by such large projects. The only reason I suggested phpDocumentor was due to the fact that it's used by Zend for their APIs for things like Facebook or GMail or Google Calendar.
As for the license, I still don't have a clue. I want to force plugin devs to share their code as a requirement within the license. That would tip toward GPL. But I also like freedom of code with freedom of use, and that would go towards the Apache / MIT license. Not forgetting that I'm going to have to make a class that can be shared between LFSWorldSDK and this so that I can convert strings to UTF-8, and HTML / ECMA-48 and times between the current hunderth-of-a-second to string ... Hell that's as easy as dividing by 100 and using the date function within PHP.
Morpha and Ripnet might also notice that I've added them as admins to the PHPInSimMod project on sourceforge. Both have already submitted code (Ripnet did the startup functions, and Morpha did the Socket API Classes.) So I'm just waiting for myself to finish off the basic networking, and then we will ship out the pre alpha.
I've not seen Ripnet in a while, so I don't know what he is up to or if he has seen the PRISM short name yet. But assuming he has picked that name, I've used that to outline most of the built in commands, and it's being used in the source code.
As far as documentation engine, I'll use doxygen, just because it's used by such large projects. The only reason I suggested phpDocumentor was due to the fact that it's used by Zend for their APIs for things like Facebook or GMail or Google Calendar.
As for the license, I still don't have a clue. I want to force plugin devs to share their code as a requirement within the license. That would tip toward GPL. But I also like freedom of code with freedom of use, and that would go towards the Apache / MIT license. Not forgetting that I'm going to have to make a class that can be shared between LFSWorldSDK and this so that I can convert strings to UTF-8, and HTML / ECMA-48 and times between the current hunderth-of-a-second to string ... Hell that's as easy as dividing by 100 and using the date function within PHP.
Morpha and Ripnet might also notice that I've added them as admins to the PHPInSimMod project on sourceforge. Both have already submitted code (Ripnet did the startup functions, and Morpha did the Socket API Classes.) So I'm just waiting for myself to finish off the basic networking, and then we will ship out the pre alpha.
Sooo... Where's my access :P
We can't use GPLv3 as it will not allow for us to link to other open source application licenses, and as I'm going to be making some more MIT Licensed code to use in LFSWorldSDK and this, we have to omit this license from the list of possibility's.
- Apache License version 2
- modified BSD license
- GNU Lesser General Public License, does not allow us to change liceses with software revisions. (I don't like that, but I'll still consider it.)
- MIT license
- Python Software Foundation License 2.0.1; 2.1.1 and newer
- W3C Software Notice and License
http://en.wikipedia.org/wiki/PHP_License
I don't read it that way... I read it as if I went and forked PHP to a new project.. I would have to call it like DHP or something.. An actual item, like PHPBB or PHPNuke.. those are allowed.
Good point, I had completely forgotten about phpBB.
Also, reading into it a bit more.. if it is called PRISM like seems to be the agreed upon name.. Then it's alright as well. becuase then Prism can be the name, then PHP In Sim Mod can be its sorta.. descriptive name?. Then it keeps away from the use of the PHP title (to avoid any licence issues), while still being logical and not a random string of characters.
I've also read the PHP licence and thought about the PHP in the name, I came to the same conclusion Dustin arrived at. You're not allowed to use PHP in your project name or use it to promote you project, but that is only of concern to projects using PHP's source, not projects using the PHP interpreter to parse PHP code.
Forcing the core and modules/plugins to remain open source, in the original project (PHPInSimMod / PRISM) and in derivative works, is a good idea, I'm for that. Application authors (= end users, from our point of view), however, should not be forced to release their code as that would scare a great portion of them away.
What about commercial use?
Forcing the core and modules/plugins to remain open source, in the original project (PHPInSimMod / PRISM) and in derivative works, is a good idea, I'm for that. Application authors (= end users, from our point of view), however, should not be forced to release their code as that would scare a great portion of them away.
What about commercial use?
(DarkTimes)
DELETED
by DarkTimes
I'm trying to promote a community that will share their code. Forcing sharing of code is the only way I can think of doing that. I don't mind people using this for profit, in so far as a server host putting it on their server for their clients to use because they are not paying for PRISM, they are paying for the server. No one should get charged to use PRISM, you should not be able to make money off it, and if you are you are then that should be against the license or the terms of use.
Just so we're clear on the terminology here; Core changes, modules/plugins/addons change the way PRISM operates, applications just use the features provided by PRISM (and possibly some modules/plugins/addons).
I agree that the former should be open-source enforced, because everyone involved in any way with PRISM, be it on the development side of things or the user side, will benefit from it.
On the application side, however, things look a bit different to me. While I have no problem with forcing local (single player) applications (of which I don't think there will be many using PRISM, to be honest) to be released, multiplayer InSim applications are what sets a server apart from the others. That's their de facto primary purpose when connected to a multiplayer host. InSim allows one to individualise the experience and create something unique. PRISM should extend on that and allow everyone (who's fluent in PHP) to express themselves. Improving the tool together is great and should be enforced, but taking away the individuality and/or uniqueness of an application by forcing the author to release his creation is not my desire.
Having run a reasonably successful server for the past 2 years, I dare say the InSim application running on a server makes between 50% and 90% of its popularity, depending on what type of server it is. If we permit use without the need to share the application, we may get some code back voluntarily, but if we force authors to release, they might choose not to use PRISM at all. I'm pretty sure I wouldn't release DriftWars's InSim and I don't think Krammeh would want to release LTC.
I think that plugin authors would develop a following in that when they are testing new plugins they are going to do it first on their server. So people that set them selfs apart from other plugin authors would not only help the community they would also increase the popularity of their 'home' server.
I feel that some of the best programmers would pick up projects that the community would want to use or see and add them to PRISM's plugin repertoire. Showing who is the best programmers, and who are just programmers. What's more we all see applications that are closed sourced out there, many of them the same thing, or basic copys of another. I don't see why PRISM can't replace these systems outright with plugins alone. I see PRISM not only as the plugin glue interface, but also as a metamod type system, where it sits between the server admin the client, and not only allows for more then the 7 current insim systems (by refactoring their code into a plugin) to work togeather, but also allow for the ease of use for the end user via a help menu that's cross plugin. Also allowing for more then 256 buttons to be shown by only showing 256 buttons at a time. It should work around the current insim problems, and fix other's outright.
I would have to agree with you on that one. The only 'popular' event that I held, was run with a custom InSim application. So you might have a point.
@Dawesdust, your going to be a plugin author I would imagine. Would you use the system if your plugins are forced into the open domain by the license or the Terms of Service?
I don't mind this myself ... but then I would'nt. But then I'm releasing the whole insim as free and open source, so I'm not a good example of a normal plugin author. What do you guys feel? Be honest, because this is going to shape how this project comes out.
Me personally, I am kinda undecided. I was part of a team for a closed source app. I dont have an issue sharing my source, as im sure I make mistakes and others could fix or tweak them. On the other hand, if I made some awesome server system, I wouldn't want 900 of a server system opening. Forcing openness would lead to a bad situation. I think it should be just strongly encouraged to open a plugin.
We could do that. I'm going to be making open source version of things like CTRA because the community has a demand for that. It won't be in version 1.0.0 or anything like that, it would be a spin off plugin and module an extra thing to download if the sever wants to run a system like that.
I'm making Live Tracker for PHPLFS-like InSim system.
I'm not going to relase source code but I'll set up it for ppl that asked me for it. On subdomains ofc.
I'm not going to relase source code but I'll set up it for ppl that asked me for it. On subdomains ofc.
PHP5 - InSim Mod.
(120 posts, started )
FGED GREDG RDFGDR GSFDG