| ../irclogs/#mantishelp.2009-04-18.log | ||
| --- scribe started --- | 00:00 | |
| dhx_m | hi | 00:23 |
|---|---|---|
| nuclear_eclipse | hi dhx_m | 00:33 |
| * paul_ has found a friend :) | 00:50 | |
| nuclear_eclipse | I've noticed... | 01:10 |
| dhx_m | paul_: any thoughts on my branch @ http://git.mantisforge.org/w/mantisbt/dhx.git?a=shortlog;h=refs/heads/10330 | 01:54 |
| dhx_m | related to one of your recent patches, I tried to get default values for BugData from the config file | 01:59 |
| dhx_m | but couldn't get that to work... http://git.mantisforge.org/w/mantisbt/dhx.git?a=commitdiff;h=7eae39da86c454df9b92055b6701e46f68c5b297 | 01:59 |
| dhx_m | I just noticed the Mantis bug tracker @ http://opensimulator.org/mantis/my_view_page.php | 02:38 |
| dhx_m | has a status specifically to indicate that the reporter (or someone else) has provided a patch | 02:38 |
| nuclear_eclipse | out of date :P | 02:38 |
| dhx_m | I was thinking that something like this would be useful on the mantisbt tracker? | 02:39 |
| nuclear_eclipse | security loopholes waiting to happen ;) | 02:39 |
| dhx_m | yeah haha | 02:39 |
| dhx_m | I actually found their tracker after google searching information on best practices for filing bug reports | 02:39 |
| nuclear_eclipse | dhx_m: we generally prefer to attach the 'patch' tag to issues with patches | 02:39 |
| dhx_m | http://opensimulator.org/wiki/Bugs | 02:40 |
| dhx_m | ok | 02:40 |
| dhx_m | I've never liked the craze over "tagging" | 02:40 |
| dhx_m | I've never seen tagging setup anywhere in a way that actually becomes useful to anyone | 02:40 |
| nuclear_eclipse | the nice thing about it allowing multi-categorization in a different dimension from primary categorization | 02:41 |
| nuclear_eclipse | s/it/is/ | 02:41 |
| dhx_m | that is what I initially thought as well when I first started researching tagging | 02:42 |
| dhx_m | then I realised that when people tag photos, documents, bugs, whatever... they tend to use non-specific tags | 02:42 |
| nuclear_eclipse | eg, primary category can determine canonical ideals, like what section/module the bug is pertaining to, while tags allow you to categorize in just about any other dimension | 02:42 |
| dhx_m | so you end up with 500 bug reports with the tags "html" and "problem" | 02:43 |
| dhx_m | and those sort of tags are all but useless | 02:43 |
| nuclear_eclipse | for the most part, it's worked out well enough on our official tracker | 02:43 |
| dhx_m | yep, it is OK when you have a predefined set of tags that people use correctly | 02:43 |
| dhx_m | like "patch" to indicate a patch is ready | 02:43 |
| dhx_m | however that is now really an orthogonal field and would be better implemented with a checkbox IMO | 02:44 |
| * nuclear_eclipse dislikes adding statuses for things like that because it starts to overcomplicate things | 02:44 | |
| dhx_m | I agree that "patch included" is not a status | 02:44 |
| nuclear_eclipse | tagging is "better" for a lot of things because it allows "ground up" associations | 02:45 |
| dhx_m | if you look on Wikimedia Commons, their category system is something I prefer over tagging | 02:46 |
| nuclear_eclipse | eg, anyone can decide to add a new dimension of categorization by creating a new tag and using it for their own purposes, and then others benefit by picking up on those tags | 02:46 |
| dhx_m | you get more useful categorisation than people tagging a photo of a house with tags like "blue sky", "there is a tree in the background", etc | 02:46 |
| dhx_m | yep, but the problem is most people won't spend time creating useful tags | 02:46 |
| nuclear_eclipse | well, I think it only works in that respect because people are much more serious about editing wiki pages than tagging photos... | 02:46 |
| dhx_m | and when they do, you don't have synonyms to treat tags "patch" and "fixed" the same | 02:47 |
| dhx_m | (a bad example... but different people will use different words to indicate the same thing) | 02:47 |
| nuclear_eclipse | ie, if anyone can edit wiki pages, anyone can start adding new categories at will; they just have a culture in place that discourages that behavior | 02:47 |
| dhx_m | they don't discourage new categories from what I've experienced | 02:49 |
| dhx_m | however they will be quick to merge duplicate/similar categories together | 02:49 |
| nuclear_eclipse | well, that and they have hundreds of devoted editors policing edits to make sure they're in context | 02:49 |
| dhx_m | "Schools in New York" and "Educational institutions for children in New York" will quickly get merged | 02:49 |
| dhx_m | yep | 02:49 |
| nuclear_eclipse | if we had people with nothing better to do than police tagging efforts, we'd see the same sort of cleanup | 02:50 |
| dhx_m | and most tag based systems don't give you the same editing ability | 02:50 |
| dhx_m | I guess... but they wouldn't have many tools to help them | 02:50 |
| nuclear_eclipse | dhx_m: manage_tags_page goes a long way towards that ;) | 02:50 |
| dhx_m | I actually like that idea | 02:51 |
| nuclear_eclipse | "merging" a tag should be as simple as finding two similar tags, selecting the merger's filter, mass-tagging those issues with the mergee, then deleting the merger | 02:51 |
| dhx_m | although there is no concept of hierarchy | 02:51 |
| dhx_m | true | 02:52 |
| dhx_m | I guess you could create your own hierarchy by searching bugs with multiple tags attached | 02:54 |
| * nuclear_eclipse is not sure that a bugtracker really needs hierarchical categorization.... :P | 02:54 | |
| nuclear_eclipse | it's much more obvious of a feature for a wiki/documentation environment, but I'm not sure how useful it really is for bug tracking purposes | 02:55 |
| dhx_m | well let's say you want to tag a bug with "utf8" and "websvn" | 02:55 |
| nuclear_eclipse | especially considering that a bug's project and category are already a sort of "hierarchical" categorization in themselves | 02:56 |
| dhx_m | but that issue also affects the git source code integration plugin | 02:56 |
| dhx_m | you'd really need to change that tag to "sourceintegration" as it covers multiple other tags | 02:56 |
| dhx_m | ie. a tag which encompasses a group of tags | 02:56 |
| dhx_m | yep | 02:56 |
| dhx_m | in a tag based system, don't you lose the ability to see that a bug tagged "utf8" and "sourceintegration" also affects other sub-modules? | 02:58 |
| nuclear_eclipse | combine the use of a project that encompasses all of the source integration project, a category to determine the primary module causing the problem, and tags for marking ancillary relations, I think it's covered... | 02:58 |
| * dhx_m notes that it wouldn't always be the case where a parent issue affects the child modules | 02:58 | |
| nuclear_eclipse | oh, and add to that the ability to have nested projects, each with their own set of local or inherited categories... | 02:59 |
| dhx_m | guess so... I just don't see how tags are needed when we have categories | 02:59 |
| dhx_m | yep | 02:59 |
| dhx_m | they seem to be duplicating a lot of information, or providing categorisation which is too vague to be useful | 03:00 |
| dhx_m | or too specific to be useful (tags that are only used once are useless) | 03:00 |
| nuclear_eclipse | well, the thing tags have over categories is a) having multiple tags per issue, and b) sharing a global set of tags to compliment project-specific categories | 03:00 |
| dhx_m | couldn't you achieve much the same thing (while forcing orthogonality) by allowing bugs to be part of multiple categories | 03:01 |
| dhx_m | and having the ability to share categories between projects? | 03:01 |
| dhx_m | I guess my main concern is that you can't nest tags | 03:03 |
| dhx_m | oh well, this is very off-topic :) | 03:05 |
| dhx_m | and isn't what I'd really consider a priority of mine with regards to Mantis development :) | 03:05 |
| nuclear_eclipse | dhx_m: well, you can already "share" by the new global and inheriting categories of 1.2.x... | 03:05 |
| dhx_m | yep | 03:05 |
| * nuclear_eclipse thinks nesting of tags would be a nightmare to maintain as well | 03:06 | |
| nuclear_eclipse | eg, then you start to get into duplication of tags via A->C and B->C | 03:07 |
| dhx_m | http://en.wikipedia.org/wiki/Tag_%28metadata%29#Advantages_and_disadvantages | 03:07 |
| nuclear_eclipse | and then the interface complexity increases by at least an order of magnitude | 03:07 |
| dhx_m | that basically covers my main arguments against tagging | 03:08 |
| dhx_m | yep | 03:08 |
| dhx_m | the "orange" tag example is a good one IMO | 03:08 |
| dhx_m | does the tag "orange" refer to the fruit or the color? | 03:08 |
| nuclear_eclipse | both :P | 03:08 |
| nuclear_eclipse | eg, an orange is orange, who the hell cares? ;) | 03:09 |
| dhx_m | hmmm I can see how searching for "orange AND letterboxes" won't return pictures of fruit | 03:10 |
| dhx_m | I guess I should read up on http://en.wikipedia.org/wiki/Ontology_%28computer_science%29 | 03:11 |
| dhx_m | seems like an interesting area of computer science | 03:11 |
| nuclear_eclipse | I think the biggest advantage of tagging in general is exactly because of it's lack of structure; users are free to use it to their needs, and it grows in usefulness as people learn how to use it better and more accurately | 03:11 |
| dhx_m | true | 03:12 |
| nuclear_eclipse | Mantis kind of does that ontology bit; when you view a tag, you can also see "related" tags, which are the tags which have been most often attached to the same bugs as the originating tag | 03:13 |
| dhx_m | but to be useful, you probably still need a large contingent of "tag editors" that know how to tag things properly | 03:13 |
| dhx_m | that's a nice feature :) | 03:13 |
| nuclear_eclipse | so you can psuedo-"explore" the tag data by hopping between related tags | 03:13 |
| nuclear_eclipse | I think probably a good feature to add to the manage_tags_page, or to the tag_view_page, would be something like what you brought up: a method of simply and directly merging one tag into another | 03:14 |
| nuclear_eclipse | it would allow "editors" of a sort to find similar tags and merge them, bringing the union of attached issues under one tag name | 03:15 |
| dhx_m | I like the "tag description" as well :) | 03:15 |
| dhx_m | yep | 03:15 |
| dhx_m | it is already easy enough to remove tags that are too vague | 03:16 |
| dhx_m | "problem" is completely useless on a bug tracker, for instant | 03:16 |
| dhx_m | *instance | 03:16 |
| nuclear_eclipse | tags are actually a generalized derivation of a feature my company uses in our existing home-brew tracker, which we use for associating release "keywords" to issues that are "hot " for any given release date/event | 03:17 |
| nuclear_eclipse | the interface is *much* nicer for Mantis though :P | 03:17 |
| dhx_m | I can imagine :) | 03:18 |
| nuclear_eclipse | actually, about 75% of the work I've put into new features for Mantis have been driven by the needs of my employer | 03:19 |
| dhx_m | It's great that they realise the benefits of contributing to an open source project | 03:19 |
| nuclear_eclipse | biggest of that being the plugin framework, which allows us to implement proprietary features outside the main codebase, and allowing us to update Mantis without having to go insane keeping our local modifications in sync with every release | 03:20 |
| dhx_m | yep, the plugins feature is really neat :) | 03:20 |
| nuclear_eclipse | dhx_m: I'm giving a talk tomorrow on the Source Integration framework at BarCamp Rochester, you should fly around the globe to attend :P | 03:26 |
| dhx_m | nuclear_eclipse: haha, good luck with the talk :) | 03:27 |
| nuclear_eclipse | thanks :) | 03:27 |
| dhx_m | are you aiming to convert people to use Mantis? :p | 03:27 |
| nuclear_eclipse | naturally ;) | 03:28 |
| dhx_m | haha | 03:28 |
| nuclear_eclipse | I figure I should leave a good impression on my fellow classmates, and maybe I can grow the userbase for the Mantis of Tomorrow :P | 03:28 |
| dhx_m | turn up to any talks on other bug trackers and ask them hard questions | 03:29 |
| dhx_m | wait for them to say "which bug tracker can do that" and then you have a wide open opportunity heh | 03:29 |
| nuclear_eclipse | lol | 03:29 |
| dhx_m | how many people are expected to attend? | 03:30 |
| nuclear_eclipse | I think I'm actually the only one talking about bug trackerrs out of the 100+ attendees | 03:30 |
| dhx_m | most of them probably use bugtrackers though | 03:30 |
| nuclear_eclipse | you'd be surprised... | 03:30 |
| dhx_m | oh :o | 03:31 |
| dhx_m | I thought it was virtually fundamental to most software development | 03:31 |
| nuclear_eclipse | about half of the students I meet don't even use source control unless they're forced to for an assignment, but perhaps that's because RIT still starts students off with CVS.... | 03:31 |
| dhx_m | Mantis doesn't really do a great job at the moment for Agile software development | 03:31 |
| dhx_m | ugh CVS! | 03:32 |
| nuclear_eclipse | exactly | 03:32 |
| dhx_m | but I would have thought most developers use some software project management software | 03:32 |
| nuclear_eclipse | it was only this year that they started officially running SVN repos for student projects | 03:32 |
| dhx_m | to track releases, bugs, what needs to be done before other stuff, etc | 03:32 |
| dhx_m | ugh SVN! | 03:33 |
| dhx_m | :) | 03:33 |
| dhx_m | well I'm a student doing a project at the moment, so I guess I fall into that category | 03:33 |
| dhx_m | and we're forced to use an SVN repo | 03:33 |
| dhx_m | but we're not forced to use anything else | 03:34 |
| nuclear_eclipse | dhx_m: it seems that RIT should really be teaching students that good tools are a big piece of the development process, but it seems to go over the professors' heads.... =\ | 03:34 |
| dhx_m | maybe RIT's courses are more focussed on computer science (maths, algorithms, etc)? | 03:34 |
| dhx_m | rather than having a focus on software engineering? | 03:34 |
| nuclear_eclipse | even in the Software Engineering department (my degree), where we focus much more on how to make projects succesful, barely anything is ever spent on using tools other than metrics and documentation tracking tools | 03:35 |
| nuclear_eclipse | RIT pioneered undergraduate Software Engineering :P | 03:35 |
| nuclear_eclipse | and yes, the normal CS department is even worse when it comes to using source control tools... | 03:36 |
| dhx_m | are they into Agile/SCRUM/etc... or do they prefer to teach more traditional methods? | 03:36 |
| dhx_m | well you can do CS without ever touching a computer | 03:36 |
| dhx_m | because it is mostly just mathematics | 03:36 |
| nuclear_eclipse | they're actually rather balanced; they discussed both side sof the coin, but I guess they lean more towards the "agile" methods | 03:37 |
| dhx_m | yeah I get that in my course too | 03:37 |
| dhx_m | although I don't think your average developer is good enough to estimate the time taken to perform a task | 03:38 |
| nuclear_eclipse | agreed | 03:39 |
| dhx_m | which limits the uses of Agile | 03:39 |
| nuclear_eclipse | yeah | 03:39 |
| dhx_m | and I also hate hard deadlines | 03:39 |
| nuclear_eclipse | one thing that bugs me about the SE and IT departments here is their giant lean towards Microsoft technologies... | 03:39 |
| dhx_m | .NET? | 03:40 |
| nuclear_eclipse | the CS department is the only one that still heavily relies on Unix and Solaris machines | 03:40 |
| dhx_m | you're lucky... mine just scrapped most of their remaining Linux labs in favour of Windows labs | 03:40 |
| dhx_m | and they do really stupid (IMO) things like running mingw with gcc on Windows | 03:41 |
| nuclear_eclipse | XP on all the lab computers, a basic "shunning" of anything Linux based, although they ironically use a Debian machine for hosting their Windows AD domain :P | 03:41 |
| dhx_m | why emulate Linux on Windows... when you can just use Linux | 03:41 |
| dhx_m | haha | 03:41 |
| dhx_m | the other thing that bugs me is teaching computer science students to learn GUI methods with one particular piece of software | 03:42 |
| dhx_m | example: TortoiseSVN | 03:42 |
| nuclear_eclipse | yeah | 03:42 |
| dhx_m | without the students ever understanding how it works in the background | 03:42 |
| nuclear_eclipse | we "learned" CVS via the Eclipse plugin =\ | 03:42 |
| dhx_m | when they go into industry and are forced to use another VCS, they are going to have a problem | 03:43 |
| nuclear_eclipse | yeah | 03:43 |
| dhx_m | I only started using git a few weeks ago, but it was made much easier because I already knew how VCS fundamentally work | 03:43 |
| nuclear_eclipse | one of my professors still couldn't see what the big deal was with Git/Hg as compared to SVN, even in the context of open source software groups scattered around the globe... | 03:43 |
| dhx_m | if all I knew was what buttons I need to click, it would have been a complete disaster | 03:44 |
| dhx_m | give him a link to the KDE SVN repos :p | 03:44 |
| dhx_m | and tell him to download it | 03:44 |
| nuclear_eclipse | lol | 03:45 |
| dhx_m | they're going towards 1,000,000 commits | 03:45 |
| nuclear_eclipse | wow | 03:46 |
| dhx_m | revision 955591 at the moment | 03:46 |
| nuclear_eclipse | that's starting to actually approach statistical collision territory for something like MD5 :P | 03:46 |
| nuclear_eclipse | good thing Git uses SHA-1 ;) | 03:46 |
| dhx_m | yeah MD5 wouldn't be my checksum of choice | 03:46 |
| dhx_m | wow... an ontology model for bug reporting: http://www.ifi.uzh.ch/ddis/evo/ | 03:52 |
| nuclear_eclipse | that descriptieon goes above my level of comprehension, or caring for comprehension.. . :P | 03:53 |
| dhx_m | haha | 03:53 |
| nuclear_eclipse | remind s of just about every academic idea for new software -- way too academic and theoretical for any proctical use :) | 03:54 |
| dhx_m | I'm not sure I like the traditional method for reporting bugs at all | 03:54 |
| dhx_m | priority, severity, resolution, milestones, versions, etc aren't that useful anymore | 03:55 |
| dhx_m | well at least not in distributed open source environments | 03:55 |
| nuclear_eclipse | I think it depends on the project in question | 03:55 |
| dhx_m | I prefer to look at it from the perspective "we want X"... to get there, we need to do A, B and C first | 03:55 |
| dhx_m | that is enough in itself to determine priorities | 03:56 |
| dhx_m | even if A is required by X, Y and Z | 03:56 |
| nuclear_eclipse | resolution is a good indicator of how a bug was "completed", either in "worksforme", "notabugitsafeature", or "fuckofficommitteditalready" :P | 03:56 |
| dhx_m | and B is only required by X | 03:56 |
| dhx_m | it is easy to see that A is probably going to be more important to complete first | 03:56 |
| dhx_m | haha | 03:57 |
| nuclear_eclipse | and milestones are still rather useful for planning and reviewing releases | 03:57 |
| dhx_m | well AFAIK, it is really only acts as a sub-status to "Closed" | 03:57 |
| nuclear_eclipse | well, yes | 03:57 |
| dhx_m | I just thought open source projects are moving away from versioning their software | 03:58 |
| dhx_m | ie. the Linux kernel | 03:58 |
| dhx_m | it hasn't happened yet, but that appears to be the general direction | 03:58 |
| nuclear_eclipse | some might be moving away from monolithic release versioning, but it still has a well defined release cycle and process for planning and reviewing release goals | 03:59 |
| nuclear_eclipse | or you look at Ubuntu, and they've dropped "normal" versioning for date-based release numbering | 03:59 |
| nuclear_eclipse | but Ubuntu has an even more rigid and defined milestone process than the kernel does | 04:00 |
| dhx_m | yep, but they never really had a use for major/minor versioning | 04:00 |
| dhx_m | the idea of major/minor versioning is to denote when you break backwards compatibility (at least I think this is how it is often used) | 04:00 |
| nuclear_eclipse | well, yes, but a version is just another way of tracking milestones | 04:00 |
| dhx_m | some projects might have architecture.major.minor or more version numbers | 04:00 |
| nuclear_eclipse | version numbers and milestones are really just a set of named node in a DAG of development process | 04:01 |
| dhx_m | yep | 04:02 |
| nuclear_eclipse | Git could name their versions after the hash ID of the version's tag, and the only thing lost is the sanity of its users... : | 04:02 |
| dhx_m | but would you say Mantis development has milestones? | 04:02 |
| nuclear_eclipse | I would, but just in another context | 04:02 |
| dhx_m | it seems to me it is more a case of "let's see what is ready to commit, and we'll add it as we feel like it" | 04:03 |
| dhx_m | sure, individual developers can agree on "let's work together to get feature X done first" | 04:03 |
| dhx_m | but if that wasn't completed, would you hold back on a release for a year? | 04:04 |
| nuclear_eclipse | our milestones are a coalescence of features at the pace that allows us to both have major features and allow us to maintain a stable release for a reasonable time period; there just isn't any planned release timeframe that many other projects have, mainly because of a lack in developer time | 04:04 |
| nuclear_eclipse | I would assume that if we had more developer manpower, we could easily stick to a more timely schedule of releases, but at the same time, it's not really as important for Mantis as it is for other projects | 04:05 |
| dhx_m | I wouldn't have said it is important at all, now that git is being used | 04:06 |
| dhx_m | because you can test new features in branches | 04:06 |
| nuclear_eclipse | hell, we can't even get our users to update to a release that's been out for months :P | 04:06 |
| dhx_m | and dump them into the master when they're more-or-less deemed OK by the people testing those branches | 04:06 |
| nuclear_eclipse | I can't even tell you how many users and bug reports we get where people are still running 1.0.x or a really old 1.1.x release | 04:06 |
| dhx_m | and then they're tested by the "beta testers" | 04:06 |
| dhx_m | and finally, you might take a snapshot of the master repo from 2 months ago and call it stable | 04:07 |
| dhx_m | I know what you mean | 04:07 |
| nuclear_eclipse | dhx_m: that's still putting a lot of emphasis on having manpower to test those branches and determine their suitability for merging to master... =\ | 04:07 |
| nuclear_eclipse | and we just don't have that amount of developer time to sustain that level of process | 04:08 |
| dhx_m | I think it'd be OK to merge branches after just the developer has tested it and another developer has quickly looked at it | 04:08 |
| dhx_m | yep | 04:08 |
| dhx_m | (I'm talking about major changes) | 04:09 |
| nuclear_eclipse | dhx_m: that's basically what we're at right now; for anything more than a simple fix or change, we've begun the habit of creating a branch on mantisforge with our changes, and then poke/bitch enough until another dev gets the time to look at it | 04:09 |
| nuclear_eclipse | and sometimes, even that doesn't happen quickly | 04:10 |
| dhx_m | yep, so what we really need is more "beta testers" for these branches? | 04:10 |
| nuclear_eclipse | it took months for my 'revisions' branch to get a once-over by anyone | 04:10 |
| nuclear_eclipse | dhx_m: not necessarily beta testers, but more developer manpower | 04:10 |
| dhx_m | if I had of been here earlier, I'd have jumped all over it :) | 04:10 |
| dhx_m | with paul's date branch, I could test it... but I don't really know what I'd be testing at the moment | 04:11 |
| nuclear_eclipse | ie, I'd rather have a developer question my feature and why I did things the stupid way I did them, than have a random tester blindly test the feature and tell me "it works" | 04:11 |
| dhx_m | true | 04:11 |
| dhx_m | I guess you get this problem in even the Linux kernel | 04:12 |
| dhx_m | someone will write a really specific piece of code that no one else could ever possibly want to use | 04:12 |
| dhx_m | so it won't undergo the same amount of testing | 04:12 |
| nuclear_eclipse | like for paulr's bugobjects branch: I lookde at it, and was able to see that some of it was inefficient/superfluous; a beta tester would have never even have noticed | 04:12 |
| dhx_m | what did you say earlier about the __get and __set methods? | 04:14 |
| dhx_m | they seem fairly good to me, because it allows plugins to specify additional metadata for a bug? | 04:14 |
| nuclear_eclipse | well, yes and no | 04:14 |
| dhx_m | in terms of performance, it looks hideous :p | 04:15 |
| nuclear_eclipse | the biggest point I had is that he used __set() to validate and normalize input data, but at that point, __get() wasn't really doing anything other than eat up cycles by adding yet another funciton call for every property access | 04:16 |
| dhx_m | yep | 04:16 |
| nuclear_eclipse | and I'd rather see any plugin to subclass the BugData object add more public properties -- you don't need __get() to do that | 04:16 |
| dhx_m | but is PHP like C++ where the get and set methods are effectively inlined? | 04:16 |
| nuclear_eclipse | and I'd rather see standardized and consistent API calls to get special data than duplicate and/or hide that functionality inside classes | 04:17 |
| dhx_m | yep | 04:18 |
| nuclear_eclipse | dhx_m: no, without __get(), it's essentially an array access; with __get(), every property access becomes a function call, which eats stack and performance | 04:18 |
| dhx_m | well not even that... why can't you just say "$bug->resolution = $t_new_bug_resolution;" | 04:18 |
| dhx_m | I guess you'd need a function if you want to check the resolution is OK | 04:18 |
| nuclear_eclipse | you can | 04:18 |
| nuclear_eclipse | the point of __set() is to transparently validate the type of data being assigned to that property | 04:19 |
| nuclear_eclipse | but once you've validated data going into the object, there's no real need for __get() to do do fancy things on the way out | 04:20 |
| dhx_m | but protected variables can't be read by other non-related classes though | 04:20 |
| dhx_m | yep | 04:20 |
| dhx_m | is it possible to have one function per field that is being set? | 04:21 |
| nuclear_eclipse | dhx_m: that's the "beauty" of __get()/__set(); because they are now class-level methods, they can still access those properties, and because they can techically be called for *any* property, even ones that don't exist, you lose the built-in protections | 04:21 |
| nuclear_eclipse | dhx_m: that's called getMyProperty() and setMyProperty() type of methods you see whoring up Java apps... | 04:21 |
| dhx_m | don't get me started on Java :p | 04:22 |
| dhx_m | I'm trying to find an example Hello World I saw on Slashdot a few years ago | 04:26 |
| dhx_m | as a joke about writing in Java | 04:26 |
| nuclear_eclipse | anywho, I need to head to bed so I can sleep before the all day event tomorrow | 04:26 |
| dhx_m | ah yep, good luck with that :) | 04:26 |
| nuclear_eclipse | cheers | 04:26 |
| dhx_m | I expect to see 50 people in this channel tomorrow hehe :p | 04:27 |
| nuclear_eclipse | lol | 04:27 |
| dhx_m | http://ask.slashdot.org/comments.pl?sid=949915&cid=24833001 | 04:27 |
| dhx_m | there it is :) | 04:27 |
| * nuclear_eclipse looks | 04:28 | |
| nuclear_eclipse | I was expecting the end of that to be more like `mb.send( DefaultFactory.getInstance().createStrategy(mb) )` :P | 04:30 |
| dhx_m | haha... that is .NET? :p | 04:31 |
| nuclear_eclipse | ok, bedtime | 04:31 |
| nuclear_eclipse | cheers | 04:31 |
| dhx_m | GetSomethingFromUser.ConvertToAnotherFormat.PerformCalculation.PrintToScreen.SaveToFile.WriteEveryStatementOnTheSameLineSeparatedByDots | 04:32 |
| dhx_m | ok cya :) | 04:32 |
| * paul_ moos | 15:47 | |
Generated by irclog2html.py