|
astr0man posted:You can do: So does it add the <? tags for you when use PHP tags?
|
# ? Mar 31, 2014 23:16 |
|
|
# ? Jun 5, 2024 09:33 |
|
zergstain posted:So does it add the <? tags for you when use PHP tags? Sure does! I did not add the `<? ?>` parts. php:<? echo var_dump("poop"); <?php echo var_dump("poop"); ?>
|
# ? Mar 31, 2014 23:33 |
|
necrotic posted:Sure does! I did not add the `<? ?>` parts. Thanks, I was a bit confused when I saw the <? ?> tags and no '$' prefixing any of the variables.
|
# ? Mar 31, 2014 23:42 |
|
seiken posted:That's bizarre and I don't know why you'd bother. Now you have to add wrapper methods for each Dictionary method you want to use.
|
# ? Apr 1, 2014 00:52 |
|
darthbob88 posted:How would I get the combined data for any particular year or month in that year? How would you get all the data from July for all the years with your current setup?
|
# ? Apr 1, 2014 01:03 |
|
I was thinking oh, just use Dictionary<Tuple<long, DateTime>, Foo> except that still nests templates... Yeah, that rule is an anti-pattern. darthbob88 posted:Interesting. I have a toy program just for storing and analyzing rainfall, which stores data in a nested dictionary, like Dictionary<Year, Dictionary<Month, Dictionary<Day, inches of rain>>>. You're suggesting I change that to Dictionary<Struct<Year, Month, Day>, inches of rain>? How would I get the combined data for any particular year or month in that year? The only way I can think of is to iterate over the keys looking for the ones with the right year and/or month, which is inefficient. A SortedDictionary, if it has a way to iterate between a range of keys. I just checked and can't see a way. Oh god speaking of coding horrors: https://stackoverflow.com/questions/5301164/how-to-find-point-between-two-keys-in-sorted-dictionary
|
# ? Apr 1, 2014 01:09 |
|
darthbob88 posted:Interesting. I have a toy program just for storing and analyzing rainfall, which stores data in a nested dictionary, like Dictionary<Year, Dictionary<Month, Dictionary<Day, inches of rain>>>. You're suggesting I change that to Dictionary<Struct<Year, Month, Day>, inches of rain>? How would I get the combined data for any particular year or month in that year? The only way I can think of is to iterate over the keys looking for the ones with the right year and/or month, which is inefficient. Yeah, I guess it's not totally equivalent if you're actually making use of the nesting structure because you want to find all elements based on a partial key. Most of the time you see this it's not the case though and you're only actually looking up single elements for which you know the entire key. If looking up values based on part of a key is super important though, you might want a slightly different structure anyway: with the nested dictionary approach, looking up based on the innermost part of the key is a bunch more expensive than looking up based on the outermost part of the key. seiken fucked around with this message at 01:15 on Apr 1, 2014 |
# ? Apr 1, 2014 01:12 |
|
quote:llvm[0]: ***** Completed Debug+Asserts Build This happens at the end of the build
|
# ? Apr 1, 2014 01:16 |
|
darthbob88 posted:Interesting. I have a toy program just for storing and analyzing rainfall, which stores data in a nested dictionary, like Dictionary<Year, Dictionary<Month, Dictionary<Day, inches of rain>>>. You're suggesting I change that to Dictionary<Struct<Year, Month, Day>, inches of rain>? How would I get the combined data for any particular year or month in that year? The only way I can think of is to iterate over the keys looking for the ones with the right year and/or month, which is inefficient. How big is the data set? Your solution seems insane for small or even moderate data sets...so many tiny nested hash tables. There have been roughly 40,000 days since 1900. That's small enough to store and filter via LINQ operations on a Dictionary<DateTime, float> without too much concern, unless you're doing a ton of filter operations in a tight loop or something.
|
# ? Apr 1, 2014 01:17 |
|
shrughes posted:Oh god speaking of coding horrors: https://stackoverflow.com/questions/5301164/how-to-find-point-between-two-keys-in-sorted-dictionary quote:I don't think there is a function on SortedDictionary that lets you find elements around the one you need faster than iterating elements. (+1 to BrokenGlass solution)
|
# ? Apr 1, 2014 01:25 |
|
Style rules and appropriate collection type for purpose are two different issues. If you're looking to perform a variety of queries on a data-set large enough that searching through all the elements is a performance problem then Dictionary is the wrong collection type. If a Dictionary<Year, Dictionary<Month, Data>> is the appropriate collection type then it comes down to a trade-off between the boilerplate necessary to do it stylishly and the benefits.
|
# ? Apr 1, 2014 01:33 |
|
Nippashish posted:How would you get all the data from July for all the years with your current setup? Iterating over each year to find ones which include days in July requires less time than iterating over all days to find ones in July, although that advantage would probably be lost iterating over each day in each July. seiken posted:Yeah, I guess it's not totally equivalent if you're actually making use of the nesting structure because you want to find all elements based on a partial key. Most of the time you see this it's not the case though and you're only actually looking up single elements for which you know the entire key. Ithaqua posted:How big is the data set? Your solution seems insane for small or even moderate data sets...so many tiny nested hash tables.
|
# ? Apr 1, 2014 02:57 |
|
What's the catch other than the string can parse to a really big number? Unrelated but, I kinda dislike those things because I can never see the catch and it makes me feel stupid. but I still want to punch this guy.
|
# ? Apr 1, 2014 03:10 |
|
JawnV6 posted:No. It's not "pretty much do the same thing." You're advocating forking the production code base, hiding all these changes from your tools, then pretending that testing this not-production code has any meaning. Who's in charge of making sure the fake code base and the production code base are in sync? You change the interface of the actual code to be pass-from-above, and invoke it from a test harness. Why would you fork anything? Do none of your functions take parameters, and instead get their data from a hairball of global state? Edit: code:
In JS, isn't that just code:
? Subjunctive fucked around with this message at 04:26 on Apr 1, 2014 |
# ? Apr 1, 2014 04:20 |
|
HardDisk posted:I kinda dislike those things because I can never see the catch and it makes me feel stupid. Just wait until the catch is a real customer case and you just broke service for them for days.
|
# ? Apr 1, 2014 05:13 |
|
Subjunctive posted:
Not if you're dealing with numbers larger than 2^53: code:
|
# ? Apr 1, 2014 05:28 |
|
Subjunctive posted:
That does nothing to solve the problem, right? All you've done is push the dependency up one level. And God help you if you want to add another dependency to a function, and have to go change everywhere it's called. With proper DI, here's what it looks like: code:
Easily testable (you just need to supply a different binding), and you don't need to gently caress around modifying call sites any time you need to add another dependency.
|
# ? Apr 1, 2014 05:42 |
|
Proper DI sure looks a lot like passing arguments via global variables.
|
# ? Apr 1, 2014 06:01 |
|
Good. Cram a bunch of ugly global calls into one file and leave the rest of the code base untouched. Don't fork every function or try to cram every bit of state it might ask for into the function signature.
|
# ? Apr 1, 2014 06:16 |
|
Plorkyeran posted:Proper DI sure looks a lot like passing arguments via global variables. Hardly. Dependency injection replaces constructor calls and static references -things which are already globally scoped even in a program written without DI - and allows you to easily substitute them for testing purposes. It doesn't replace passing parameters - for example, if this function was supposed to format a DateTime such that it was relative to the current time (e.g. "5 seconds ago"), you'd still pass the DateTime to format as a regular parameter. You can also do inversion of control manually by explicitly passing all the dependencies into the constructor or method call, but that results in a very fragile structure that requires changes all over the place if you want to change the dependency structure in any way, making it really hard to maintain.
|
# ? Apr 1, 2014 06:18 |
|
I don't get why people hate the constructor. It's like, jeez just pass the stuff the class needs to the constructor already.
|
# ? Apr 1, 2014 07:13 |
|
Jabor posted:And God help you if you want to add another dependency to a function, and have to go change everywhere it's called. Or, put another way: the horror is you
|
# ? Apr 1, 2014 07:42 |
|
Jabor posted:You can also do inversion of control manually by explicitly passing all the dependencies into the constructor or method call, but that results in a very fragile structure that requires changes all over the place if you want to change the dependency structure in any way, making it really hard to maintain.
|
# ? Apr 1, 2014 07:46 |
|
seiken posted:That's bizarre and I don't know why you'd bother. Now you have to add wrapper methods for each Dictionary method you want to use. For the example I posted your way would certainly be better, the current implementation is overkill as both dictionaries are tiny and the long/datetime are strongly linked. I try to not be strict; but the job I had before this treated FxCop as the be-all-end-all of programming style which would break the build on warning levels of reporting. Three years of that and my fingers get itchy when I see more than one angle bracket next to each other and it's not a shift. Then again there's this question related to a class overloading ">>" in a contrived way; http://stackoverflow.com/questions/10610459/nested-generic-syntax-ambiguity
|
# ? Apr 1, 2014 08:04 |
|
Just an example to put this stuff in context, since most enterprise software design patterns tend to be unnecessary and look clumsy for toy programs: Suppose we're building a document-management application. One of the things your document management application does is share documents between users. You've written a component to handle that sharing process. Now you want to have a widget that shares a particular document. You could have the widget instantiate an instance of your sharing component, but that's pretty untestable. You could pass in an instance when you're creating the widget, but now everything that uses the widget needs to know that it depends on your sharing component, and if you change your mind later you need to also change everything that uses your widget - it's fragile and it's not very good at encapsulating how the widget works. Using a DI framework solves the testability issue without forcing every component in your program to care about the internal workings and dependencies of every other component they make use of.
|
# ? Apr 1, 2014 08:29 |
|
JawnV6 posted:Good. Cram a bunch of ugly global calls into one file and leave the rest of the code base untouched. Don't fork every function or try to cram every bit of state it might ask for into the function signature. Hello, I write Haskell at my job, and this is pretty much necessary. As for a horror... code:
|
# ? Apr 1, 2014 09:29 |
|
Athas posted:
Is it wrong that this makes me think of Total Recall?
|
# ? Apr 1, 2014 10:10 |
|
Zombywuf posted:Is it wrong that this makes me think of Total Recall? Not at all! I was in fact thinking about what to call this pattern, given that its smaller cousin '(.) . (.)' has a pretty obvious name.
|
# ? Apr 1, 2014 10:15 |
|
JawnV6 posted:Good. Cram a bunch of ugly global calls into one file and leave the rest of the code base untouched. Don't fork every function or try to cram every bit of state it might ask for into the function signature.
|
# ? Apr 1, 2014 10:16 |
|
Athas posted:Hello, I write Haskell at my job, and this is pretty much necessary. As for a horror... Somebody learnt to program in Forth clearly e: alternatively, this is code:
gonadic io fucked around with this message at 12:06 on Apr 1, 2014 |
# ? Apr 1, 2014 10:38 |
|
Let me see if I understand this. (.) . (.) takes a function that's missing exactly two parameters and composes it with another function that expects the return type of the first function as its first input parameter. Is that right?code:
code:
code:
AlsoD posted:Somebody learnt to program in Forth clearly That is... not clearer to me.
|
# ? Apr 1, 2014 12:55 |
|
LOOK I AM A TURTLE posted:Let me see if I understand this. (.) . (.) takes a function that's missing exactly two parameters and composes it with another function that expects the return type of the first function as its first input parameter. Is that right? Yes you're correct, yes it's pretty ridiculous (hence why it's a horror). The correct way to write that function would be code:
There was a Haskell thread in CoC for a little while but it didn't see much traffic. Functional programming comes up in the YOSPOS programming thread a fair amount though if you want to discuss it there. There's also been some suggestion to recognise the boobs operators with code:
e: Although this hasn't stopped me from defining these functions when I need then in my toy code and I wouldn't hesitate to use runFunNoTrace = fst .:: runFun in a personal project. gonadic io fucked around with this message at 13:21 on Apr 1, 2014 |
# ? Apr 1, 2014 13:09 |
|
As for my horror:code:
Monoid (Solution -> Solution -> Ordering)
|
# ? Apr 1, 2014 13:29 |
|
Athas posted:Hello, I write Haskell at my job, and this is pretty much necessary. As for a horror... Sagacity posted:Is the "Fine whatEVS!" approach how you handle every discussion? You're advocating changing parameters as a way to avoid DI. I tried mentioning a case where a dependency is used twice, forcing this method to add another parameter to the function and highlight how ridiculous it is to try to avoid dependencies by smuggling all this information around in the function signature, you out on the details. I tried to retreat to the clear principle of "run tests against Actual Production Code" and you again defend your lovely parameter idea. Changing parameters either uglies up all the code everywhere or you're forking it and testing fake code against a fake environment. All of the "ugly boilerplate" you're ranting against as if it's the root of all evil is in one file apart from the production code base. So yeah, after 3~4 passes against your lovely disingenuous arguments that refuse to step back and see the forest for the trees, I guess I'm a little short and pithy. I could take another swing, but I'm pretty sure you'll just retreat to complimenting all the amazing humans you work with and avoiding the relevant bits of the discussion.
|
# ? Apr 1, 2014 14:39 |
|
Jabor posted:Hardly. Dependency injection replaces constructor calls and static references -things which are already globally scoped even in a program written without DI - and allows you to easily substitute them for testing purposes.
|
# ? Apr 1, 2014 15:39 |
|
JawnV6 posted:You're advocating changing parameters as a way to avoid DI. I tried mentioning a case where a dependency is used twice, forcing this method to add another parameter to the function and highlight how ridiculous it is to try to avoid dependencies by smuggling all this information around in the function signature, you out on the details. I tried to retreat to the clear principle of "run tests against Actual Production Code" and you again defend your lovely parameter idea. Changing parameters either uglies up all the code everywhere or you're forking it and testing fake code against a fake environment. All of the "ugly boilerplate" you're ranting against as if it's the root of all evil is in one file apart from the production code base. You're literally advocating using global variables to avoid having to pass arguments to a function.
|
# ? Apr 1, 2014 15:42 |
|
Plorkyeran posted:You're literally advocating using global variables to avoid having to pass arguments to a function. And if this EGREGIOUS SIN lets us test production code without modification? Can you put those two values up against each other and make a conscious decision or is one so utterly abhorrent that you can't give it any space? I'd welcome a nuanced argument. Saying "gloooobal" with the boogeyman voice doesn't cut it. I do embedded work. Globals are called "RAM."
|
# ? Apr 1, 2014 15:52 |
|
Well yes, we can have a discussion about when using global variables is and isn't worth it if you're done trying to claim that you aren't using global variables at all.
|
# ? Apr 1, 2014 16:00 |
|
I don't see the problem with global state as long as it is effectively immutable.
|
# ? Apr 1, 2014 16:10 |
|
|
# ? Jun 5, 2024 09:33 |
|
For example, in Python I'm moderately a fan of the following general pattern for mocking out deps for tests:Python code:
The default implementation is right next to the thing using it, rather than being off in some other class whose name may not even appear in the file. This helps reduce DI's tendency to turn code into ravioli. mock.patch is very clearly a unit testing thing. Using it to switch implementations based on a value in a config file would be obviously completely insane. OTOH, it seems to be an inevitable result of using IoC containers, since they do handle that quite well. However, this leads to your non-test code relying on mutable global state as a non-implementation-detail, which generally turns into a mess. "Don't monkey-patch classes outside of test code" seems to be a much simpler rule for people to follow than "Don't use this library that we're using for other things to solve a problem it appears to solve well but actually doesn't". It doesn't lead as much to "gently caress it, let's DI all the things, including the things that we don't actually have to mock out for tests". IoC containers are a workaround for the fact that the language makes it excessively awkward to explicitly pass in all of an object's dependencies. However, sometimes (often) an object's dependency really is a logical part of its interface and should be explicitly passed in, even though it can be magically instantiated by the DI stuff. Automatic DI should be used only for things that are implementation details of the class, but because it's "easier" it tends to get used for more than that. It of course also has far less boilerplate, but that's mostly a result of Python vs. Java (although some people do seem to really like writing Java amounts of boilerplate in Python).
|
# ? Apr 1, 2014 16:35 |