|
Your time is worth more than the computer's. Design the program well; don't worry about function or method call overhead until it actually becomes a problem (and it hopefully never will). The term I've heard for what Triple Tech is describing is decoupling.
|
# ? Dec 16, 2008 22:15 |
|
|
# ? May 21, 2024 17:04 |
|
Also, I'm not sure you need to use Tie::Handle::CSV when this is probably a lot faster:code:
|
# ? Dec 17, 2008 00:17 |
|
Having silly issues with map and can't seem to get it to work the way I want. I'm sure there's a way but it's escaping me. I've got this code code:
So I try code:
I can get it to work right using code:
EDIT: Turns out this works. Why it doesn't work without an else statement, I have no idea. code:
Beardless Woman fucked around with this message at 04:02 on Dec 17, 2008 |
# ? Dec 17, 2008 03:43 |
|
Here's code that'll work:code:
code:
code:
|
# ? Dec 17, 2008 03:46 |
|
Sartak posted:working code Thanks Sartak. You're right about returning the empty string. I wound up just using a foreach loop. I shouldn't try to get too clever. EDIT: After playing around with it, turns out you simply have to have an else inside map if you're using if. Beardless Woman fucked around with this message at 12:12 on Dec 17, 2008 |
# ? Dec 17, 2008 04:04 |
|
Beardless Woman posted:Why it doesn't work without an else statement, I have no idea. So without the else, it's returning the result of the if statement which i guess is a blank string. With the else there you're returning the result of a blank block which seems to be equivalent to undef.
|
# ? Dec 18, 2008 08:11 |
|
I'm hoping someone can help me here. I've been so wrapped up in this problem that I don't think I'm capable of thinking outside the box at all. I'm writing a framework and part of that framework is an ORM. The spec for the ORM is basically this: 1) Has to handle joins which span multiple database (a MySQL 'feature'). 2) Models must be available across multiple projects and should always use the existing DB connection for that 'request' if applicable. 3) Provide CRUD functionality. So I've written a loose port of the django model system in Perl. The models look like this: code:
code:
Passing in the db instance to the constructor was fine when coming up with a proof-of-concept app for my framework with two controllers and a handful of actions. But what really started to bother me when writing the test suite was that I constantly had to pass in the db object to the constructor. Every model instance I was going to create in this test run was going to use the same settings, and the same could apply to every controller and action inside a given project - they would all be using the same settings. So in the spirit of DRY I wanted to add a new rule to the spec: 4) When used inside their native project, a model should fall back on a default connection defined by that project's config file. This has proved a lot harder than I thought. After multiple attempts, the solution that I've implemented right now is this (Moose syntax): code:
The other reason is that I plain don't like the technique I'm using here. It relies a lot on conventions and in general seems like a nasty hack. Also it doesn't really play well with a test suite. I end up having to create a directory structure idential to my project structure just to test the models.. it's so much hassle that I end up just passing in the db instance. I have thought about requiring the creation of a "base model class" for each project and the doing something like: code:
What I'd like to know is if there are any ways of achieving what I want to - essentially giving a group of classes a default property that they can inherit. When I write it like that, creating a base class seems like the most logical option. But I'd be interested in hearing other suggestions... Div fucked around with this message at 12:52 on Dec 18, 2008 |
# ? Dec 18, 2008 12:49 |
|
TiMBuS posted:the result of the if statement which i guess is a blank string The canonical false value in Perl is the empty string. For example, 1 > 3 evaluates to the empty string. The canonical true value is 1. Div posted:What I'd like to know is if there are any ways of achieving what I want to - essentially giving a group of classes a default property that they can inherit. When I write it like that, creating a base class seems like the most logical option. But I'd be interested in hearing other suggestions... I'd look at Class::Data::Inheritable. It has some quirks, but I think they are quirks you want.
|
# ? Dec 18, 2008 20:59 |
|
Not a short question, but Perl was released 21 years ago today. Yay Perl!
|
# ? Dec 19, 2008 03:28 |
|
Sartak posted:The canonical false value in Perl is the empty string. For example, 1 > 3 evaluates to the empty string. The canonical true value is 1. ( someone correct me if any of this is wrong -- going by memory) It depends on context. The way false is represented in the Perl API is &PL_sv_no, which points at a table entry that contains context-sensitive read-only scalars to be used in op evaluation. pre:$r = (1 < 0) + 0; Similarly, there is &PL_sv_yes with scalars for "1", integer 1, or double 1 and also &PL_sv_undef for the undefined value, which is a scalar flagged as null. TiMBuS posted:Because perl returns the last evaluated statement or expression in a block The last statement of the block chosen by evaluating the expression is returned. The if construct itself has no "result" (hence the '?:' operator). A perl sub just returns the values off its stack (and Perl's return statement just puts values on the stack, which is what makes it optional). pre:sub a { if(1) { 0 } else { 1 } } a(); # numeric 0, not '' s139252 fucked around with this message at 19:21 on Dec 19, 2008 |
# ? Dec 19, 2008 19:18 |
|
As it was explained to me once, the set of things that are 'false' consists of the empty string, numeric zero, and UNDEF. Conversely, the set of things that are 'true' is everything not in the set 'false'.
|
# ? Dec 19, 2008 19:33 |
|
magimix posted:As it was explained to me once, the set of things that are 'false' consists of the empty string, numeric zero, and UNDEF. Conversely, the set of things that are 'true' is everything not in the set 'false'. Yes. We're discussing which false value Perl chooses in certain situations.
|
# ? Dec 19, 2008 20:28 |
|
Sartak posted:Yes. We're discussing which false value Perl chooses in certain situations. Even in these formal shorts, I feel like a failure
|
# ? Dec 19, 2008 20:44 |
|
satest4 posted:The last statement of the block chosen by evaluating the expression is returned. The if construct itself has no "result" (hence the '?:' operator). Not so sure bout this. It has some kind of result, check it out: $a = do{}; # $a is undefined $a = do{if (1 > 2){} else{}}; # $a is also undefined here $a = do{if (1 > 2){}} # $a is defined, but false. and heres the kicker undef $a; $a = do{if ($a){}}; # $a is undefined.
|
# ? Dec 20, 2008 23:53 |
|
TiMBuS posted:Not so sure bout this. It has some kind of result, check it out: Everything is stack-based and most ops will affect the stack. $a = do{}; # $a is undefined $a = do{if (1 > 2){} else{}}; # $a is also undefined here Perl has an op called stub that pushes PL_sv_undef onto the stack (in scalar context). This is where the assignment gets undef from here. It is sort of a noop placeholder. $a = do{if (1 > 2){}} In this case, perl chooses to optimize away the evaluation of "1 > 2" during lexing and replaces it with a const op that pushes PL_sv_no onto the stack. The assignment operator provides scalar context, and above I explained PL_sv_no in a scalar context is an empty string. The optimizer actually adds a bit of non-determinism here. Interesting find. undef $a; $a = do{if ($a){}}; # $a is undefined. This can't be optimized like the last example because the statement being evaluated is not a constant expression. As with the first examples, the stub op is used when the condition is true, giving you undef again.
|
# ? Dec 22, 2008 18:39 |
|
So if statements do have a result, it's just purely coincidental because of the stack-based implementation? Hey as long as it works. But: satest4 posted:undef $a; $a = do{if ($a){}}; # $a is undefined.
|
# ? Dec 22, 2008 23:26 |
|
Someone from #cobol told me the problem I'm trying to solve at work is called "dependency injection", and it seems to be right on the money. Which would be the least evil way of accessing a hash our'ed by a package? eval or a symbolic reference? I'm trying to implement what I would call data inheritance... Like the data is structured similarly in all the subclasses, but I don't want to expend the energy (hurf) in creating accessor stubs in each subclass, since they're exactly the same. Edit: I realize this is a bit all over the place...
|
# ? Dec 23, 2008 17:18 |
|
Bread::Board might be worth looking at for inversion-of-control. Class::Data::Inheritable for your data inheritance.
|
# ? Dec 23, 2008 19:41 |
|
Triple Tech posted:Someone from #cobol told me the problem I'm trying to solve at work is called "dependency injection", and it seems to be right on the money. Are you sure you're going with the right solution? What are you trying to do this for?
|
# ? Dec 29, 2008 19:57 |
|
ashgromnies posted:Are you sure you're going with the right solution? What are you trying to do this for? The whole point of most of my CoC posts (related to this project) is that I have no idea if I'm using the right design, and that's what I'm seeking out. Let's say we have a money making process, invoked by asking a goon (identified by user id) to make money. 1) Setup. 2) ??? 3) Profit! Steps 1 and 3 are the same for every goon, implemented the exact same way. Step 2 however is entirely dependent on which goon you ask. How do you implement such a pattern? (dependency injection??) To some extent, there's object inheritance, which I'm sort of using. But inheriting a method and passing around an anonymous subroutine are the same thing. With this other process I'm making (different from the first process, but exactly the same in structure, 1, 2, profit), the "interface" if you will looks almost like a hash (value by key and collect all keys (used for testing)). So I figured, why not "inherit" a real hash. I accomplished this by just assembling the fully qualified (with package) name of the variable (this is a symbolic ref that breaks strict). Yeah, it's all over the place and I'm not proud of it. But yeah, I don't know how else to go about it.
|
# ? Dec 31, 2008 15:49 |
|
Working on something related to the previous question i had and stumbled upon this: Is there a way to to somehow "use" a bunch of modules with only one command? Preferrably while having said command being a subroutine imported from another file.
|
# ? Jan 1, 2009 02:43 |
|
use is a compile-time (clarify, someone, please) command, so the only way to really bundle it is the inclusion of another module. Just have a stuff called My::Bundle which in itself use's the other stuff. You can require at run-time, however, so you can tuck those in a subroutine.
|
# ? Jan 1, 2009 03:07 |
|
So, simply like this?code:
|
# ? Jan 1, 2009 03:19 |
|
Right.
|
# ? Jan 1, 2009 18:41 |
|
drat, was hoping i did something wrong. When i do the stuff above, subs don't end up usable in MyModule when exported by "A" as follows:code:
|
# ? Jan 1, 2009 19:48 |
|
Mithaldu posted:drat, was hoping i did something wrong. When i do the stuff above, subs don't end up usable in MyModule when exported by "A" as follows: Say you have this... code:
With "use base", you are modifying the caller's @ISA. That's probably less desirable for what you are trying to do, because (aside from other reasons) the inherited subs are visible via method resolution versus symbol table entries in the client package. You could do something like this... code:
Triple Tech posted:use is a compile-time (clarify, someone, please) command Right. Saying "use Foo" is the same as this... code:
s139252 fucked around with this message at 17:18 on Jan 2, 2009 |
# ? Jan 2, 2009 17:14 |
|
ToolSet might be helpful for this.
|
# ? Jan 3, 2009 04:43 |
|
satest4, thanks for the awesome explanation. I really should've realized that i need to export all functions that i want to carry over and i also learned something about the specifics of begin blocks. As for "use base", i honestly really don't get what you're trying to say there. I DID notice that it didn't work for transporting simply exported functions, but i don't have any idea why, since i never looked into how OO internals work in Perl. However, it really IS part of the solution for my problem here, since CGI::Application plugins attach their functions to the caller when imported and thus these functions survive the "use base" transition. I've basically made an extended version of Titanium. (And i really should've looked at its source earlier, since it's really loving simple.) My biggest thanks however go to Ninja Rope, since that is EXACTLY what i was looking for, and then some.
|
# ? Jan 3, 2009 13:33 |
|
Has anyone else been playing around with perl6 the past few weeks? I started writing a console version of Risk in p6, and was very surprised by how much is working. I got most of the classes set up with the appropriate properties and methods, and it all compiles cleanly. Right now I am putting off figuring out the best way to draw a undirected graph to the console. Does anyone know of a good example I can go off of? I did a few searches on CPAN and found very little. leedo fucked around with this message at 20:34 on Jan 4, 2009 |
# ? Jan 4, 2009 20:29 |
|
Without having looked at the code and judged its portability to p6, App::Asciio might be a good starting point. Rakudo is definitely way faster than Pugs was, though.
|
# ? Jan 5, 2009 15:10 |
|
Triple Tech posted:Someone from #cobol told me the problem I'm trying to solve at work is called "dependency injection", and it seems to be right on the money.
|
# ? Jan 5, 2009 17:36 |
|
Mithaldu posted:As for "use base", i honestly really don't get what you're trying to say there. Sorry. I was just pointing out that often it is desirable to import symbols into a package rather than rely on method resolution to get similar effect.
|
# ? Jan 6, 2009 21:45 |
|
SpeedFrog posted:Without having looked at the code and judged its portability to p6, App::Asciio might be a good starting point. That is perfect, thanks! Should give me something to do for the next few weeks.
|
# ? Jan 7, 2009 01:45 |
|
I've been regularly checking out parrot and playing with it. Rakudo isn't bad and is a lot more complete than many realize but even so, writing whole apps in it always ends up running into weird annoying bugs and frustration. I mostly just use parrot to hammer out my toy language instead of trying to work on perl6.
|
# ? Jan 7, 2009 03:16 |
|
Turns out I won't be attending either of Frozen or YAPC (even though our lovely Sartak is presenting at Frozen!! ). I'm lazy, it costs money, my company is just hemming and hawing... And, I had some other poo poo scheduled on those days as well. Sucks. I guess I have to put being an uber Perl nerd on hold for another year. Unless there other NA conferences I should know about. The cheaper the better, it seems.
|
# ? Jan 7, 2009 16:08 |
|
I don't think it gets much cheaper than YAPC. I paid for it out of pocket last year when it was in Chicago. Well worth it, IMO.
|
# ? Jan 8, 2009 00:58 |
|
Vincent Pit (author of Variable-Magic) is a beautiful man. He's been working on Scope-Upper which lets you gently caress with the stack. The feature for which Scope-Upper was written was the ability to use local on higher stack frames. This lets you abstract away syntax that was previously unabstractable! For example, in testing functions you write, you're supposed to include at the top local $Test::Builder::Level = $Test::Builder::Level + 1; to tell Test-More how to find the line of code that actually defines the test. This way when it tells you that a test failed, Test-More can report the file and line number of that test. With Scope-Upper, Test-More could now give you a function to call that manages $Test::Builder::Level for you - abstracting away that call to local. Yes, this is pretty esoteric, but it does let you do more interesting things without having to burden your users with twiddling a dynamic variable. Scope-Upper 0.04 and later give you a new procedure called unwind. This lets you return values to upper scopes! This is equivalent to an escape continuation. I'm pretty sure it's implemented reusing Perl's eval/die exception mechanism, so I trust that it properly cleans up after itself. I've wanted both of these features for a long time. Now I can build more interesting syntax. I've started tonight with Continuation-Escape which gives you a nicer interface to unwind: code:
I love this guy! Filburt Shellbach fucked around with this message at 02:45 on Jan 13, 2009 |
# ? Jan 13, 2009 02:42 |
|
My mind hurts. What's a super practical use for this? Or what properly demonstrates the power/concision tradeoff?
|
# ? Jan 13, 2009 02:52 |
|
I can't remember any particular examples for where this would be useful. In general, if you have a complicated calculation involving many functions, you may want to return from an inner function without having to bubble that return through all the outer functions. As a trivial example..code:
edit: I've remembered a recent reason why I wanted them. In Path-Dispatcher, you can "run" a "dispatch" which basically executes a list of code references. Any coderef can say "abort the entire run" or "skip to the next coderef". I use exceptions to implement this, but since neither is an exceptional case, they should be implemented with escape continuations. Once Scope-Upper is a little more vetted I'll do just that. Filburt Shellbach fucked around with this message at 03:16 on Jan 13, 2009 |
# ? Jan 13, 2009 03:09 |
|
|
# ? May 21, 2024 17:04 |
|
What's it do that this doesn't do?code:
Triple Tech posted:My mind hurts. What's a super practical use for this? Or what properly demonstrates the power/concision tradeoff? It's just a way of wrapping eval/die to be able to use it to return a value from a block instead of just an exception. For example, I could run a call_cc block, pass it's $escape ref into a sub, then pass it into a sub from inside there. I'm now two stack frames removed from the call_cc block, but I can still immediately return from the call_cc block to its caller by calling the $escape ref -- the exact same way die would unwind the stack, but the call_cc block returns normally instead of bubbling the die up the stack further. Suppose you were trying to parse a string with a recursive descent parser, and you head down some speculative parse branch several subs deep before finally realizing the parse branch doesn't work out. You can escape out some sort of failure return value without needing to write eval/die handling logic at the original callsite. biznatchio fucked around with this message at 19:38 on Jan 13, 2009 |
# ? Jan 13, 2009 19:27 |