|
it is friday night and i am having fun converting every one of my functions that creates an unnecessary new List to yield iterators instead. i'm very cool and popular
|
# ? Jul 23, 2016 05:12 |
|
|
# ? May 25, 2024 13:27 |
|
more like lazy
|
# ? Jul 23, 2016 05:16 |
|
hehe
|
# ? Jul 23, 2016 05:36 |
|
i'm checking out a bug backlog. they aren't fun lemme tell you
|
# ? Jul 23, 2016 05:42 |
|
i have crawled waaaaaaaaaaaaaay up my own rear end in a top hatcode:
|
# ? Jul 23, 2016 06:45 |
|
GameCube posted:it is friday night and i am having fun converting every one of my functions that creates an unnecessary new List to yield iterators instead. i'm very cool and popular i'm spending my friday night cloning unity's GameObject/Component system for a typescript games framework, it's been weird and the more time i spend on this the more time i am surprised unity's scripting system works half as well as it does i'm pretty sure game objects-as-buckets-of-components is an improvement on, like, traditional OOP or mixins, but seems to have a lot of problems of its own also i was looking at tutorials and trying to figure out how you'd architect a top-level "game controller" component and the answer is apparently to make a fuckin singleton so now i trust unity even less than i did before
|
# ? Jul 23, 2016 06:53 |
|
have u seen this http://gameprogrammingpatterns.com/
|
# ? Jul 23, 2016 06:57 |
|
GameCube posted:have u seen this http://gameprogrammingpatterns.com/ yea and what i'm implementing is basically http://gameprogrammingpatterns.com/component.html so far i've just happened to agree with most of how unity implements this pattern but there are places where i'd consider changing things so i should probably re-read the last section of that again
|
# ? Jul 23, 2016 06:59 |
|
abraham linksys posted:yea and what i'm implementing is basically http://gameprogrammingpatterns.com/component.html that is just one of many game programming books i read and then never acted on. godspeed
|
# ? Jul 23, 2016 07:06 |
|
my plan is to get this in a stable enough place that i can make a game with it at a game jam next weekend. if not, i will just consider it the weirdest way anyone has ever learned unity's scripting API, because I've learned more from this than any of the number of times I downloaded Unity and tried to actually make anything with it
|
# ? Jul 23, 2016 07:13 |
|
laziness can be ok as long as you aren't producing any side effects. honestly I ToList much of the time because I figure callers may enumerate return values multiple times as well. an ienumerable of ienumerables is definitely something I would raise an eyebrow at with all perf questions: don't do poo poo that's obviously inefficient, but question your assumptions and run a profiler if perf matters at all in your situation
|
# ? Jul 23, 2016 07:32 |
|
YeOldeButchere posted:welp i'm an idiot Is there a reason not to throw these into an ILP solver?
|
# ? Jul 23, 2016 07:53 |
|
fleshweasel posted:laziness can be ok as long as you aren't producing any side effects. honestly I ToList much of the time because I figure callers may enumerate return values multiple times as well. I tend to not do this. Users can call ToList on the returned collection of they need multiple enumeration. abraham linksys posted:i'm spending my friday night cloning unity's GameObject/Component system for a typescript games framework, it's been weird and the more time i spend on this the more time i am surprised unity's scripting system works half as well as it does The hardest part is cross component messaging. If you have (logically built) component dependencies then you'll want to have dependent components do things when their dependency is changed. An example in Unity is the UISprite, when you change a field on this (say the actual sprite), you'll want to message any sibling components that this has changed. There are a few ways to do this and you generally fall back to either messaging (SendMessage in Unity / maybe checking interfaces and issuing calls if siblings implement them). The complexities arise because you don't know which fields sibling components will be interested in, so you end up either having a bunch of callback in the main component that siblings can register against of a full crazy messaging system. Basically you end up with a bunch boilerplate code that you need to maintain that may or may not ever be used because you can't be sure what the sibling components will need. This isn't so much an issue of you are just writing something for a single application (just code what you need); but when you have a real system (like the Unity UI) it's really hosed and every time you miss one callback you'll have consumers of the system complaining that a callback is missing. Then you'll also have them complain that things are slow because everything has callbacks and it takes time to check / invoke them, even if they are not used. stramit fucked around with this message at 08:27 on Jul 23, 2016 |
# ? Jul 23, 2016 08:02 |
|
fleshweasel posted:laziness can be ok as long as you aren't producing any side effects. honestly I ToList much of the time because I figure callers may enumerate return values multiple times as well. quote:an ienumerable of ienumerables is definitely something I would raise an eyebrow at speaking of which, how do i profile
|
# ? Jul 23, 2016 08:05 |
|
lmfao somehow i generated almost 2000 test cases for one method. our QA manager will be very pleased with these numbers
|
# ? Jul 23, 2016 08:21 |
|
Strumpy posted:I tend to not do this. Users can call ToList on the returned collection of they need multiple enumeration. i use IEnumerable<T> as the return type but actually return List<T>. this is because most of my colleagues don't know anything about IEnumerable and multiple enumeration and iterator methods and laziness and such i also have an annoying habit of always typing IEnumberable
|
# ? Jul 23, 2016 08:22 |
|
Bloody posted:I think the answer involves taking the floor and ceiling of Cy / K and using them as Ax and Bx and then calculating appropriate Ay and By given those Ax and Bx this was my line of thinking but i didn't flesh out anything more concrete before getting drunk the was something with modulos i worked out where you could quickly check Cx*Kor something to see if there was no valid solution (but i don't think passing guarantess a solution)
|
# ? Jul 23, 2016 10:40 |
|
GameCube posted:lmfao somehow i generated almost 2000 test cases for one method. our QA manager will be very pleased with these numbers you should do property testing
|
# ? Jul 23, 2016 10:51 |
|
GameCube posted:i have crawled waaaaaaaaaaaaaay up my own rear end in a top hat if you really need those nested generics but don't want to type them everywhere, you can sometimes "alias" them depending on how you use them code:
|
# ? Jul 23, 2016 12:53 |
|
NihilCredo posted:if you really need those nested generics but don't want to type them everywhere, you can sometimes "alias" them depending on how you use them or you can alias them using a using statement at the top of the file like using Dick = System.Tuple<Pussy,Taint>
|
# ? Jul 23, 2016 14:03 |
|
that way you don't have to define new types and yeah check out property testing to go further up your own rear end and then move to F#
|
# ? Jul 23, 2016 14:04 |
|
neato - rendering is synced with vsync and locked to 35fps - objects now have a velocity vector that gets applied to their translation position every frame - coming soon: commanding objects to rotate to face (X,Y,Z) in T frames??? i'm winner
|
# ? Jul 23, 2016 15:59 |
|
if you return a list as an ienumerable people are just gonna ToList it and create a new list instance. whoops
|
# ? Jul 23, 2016 17:03 |
|
Oh does C# not have an immutable list type built in yet? I'm surprised, I would have thought they'd have one by now.
|
# ? Jul 23, 2016 17:29 |
|
AWWNAW posted:or you can alias them using a using statement at the top of the file like using Dick = System.Tuple<Pussy,Taint> huh, thought for some reason that didn't work on generics, cool fleshweasel posted:if you return a list as an ienumerable people are just gonna ToList it and create a new list instance. whoops yeah but at least they aren't gonna mess with your list that way. i think one huge reason ienumerable was returned everywhere because ireadonlylist didn't exist until .net 4.5 if you're writing a pure function, sure, you can hand over the original list no problem. but if it's a property or something you absolutely want to return an immutable interface NihilCredo fucked around with this message at 18:42 on Jul 23, 2016 |
# ? Jul 23, 2016 17:31 |
|
GameCube posted:yup i learned that lesson the hard way. what do you mean key not found?? oh my generator for a thing was an iterator that meant new objects were being created when i didn't want them to be. oops wait, what? please elaborate so i don't have to learn the hard way as well
|
# ? Jul 23, 2016 18:37 |
|
nrook posted:Oh does C# not have an immutable list type built in yet? I'm surprised, I would have thought they'd have one by now. nah, system.collections.immutable has existed for four years but people are slow to adopt it when they're already used to exposing ienumerable which 90% of the time does the job just fine
|
# ? Jul 23, 2016 18:44 |
|
NihilCredo posted:nah, system.collections.immutable has existed for four years but people are slow to adopt it when they're already used to exposing ienumerable which 90% of the time does the job just fine oh ok that's good. an advantage of immutable collections is that in any decent implementation "copying" a list is O(1). so if you make an immutable list and return it as an IList or IEnumerable and then the caller decides to make an immutable list from your return value, you aren't doing a bunch of pointless calculations
|
# ? Jul 23, 2016 18:52 |
|
GameCube posted:i have crawled waaaaaaaaaaaaaay up my own rear end in a top hat we really need some syntax sugar for what shoulda been core builtins there. 'public static [([Mome], [Chome])] Lomarf([[Mome]] momes, [[Chome]] chomes)' would look fine
|
# ? Jul 23, 2016 19:38 |
|
Gul Banana posted:we really need some syntax sugar for what shoulda been core builtins there. 'public static [([Mome], [Chome])] Lomarf([[Mome]] momes, [[Chome]] chomes)' would look fine we need to stop expanding C++, it's 2016 and you can just use a good language if you loving want to
|
# ? Jul 23, 2016 19:41 |
|
C# should have type aliases
|
# ? Jul 23, 2016 19:45 |
|
it's a lot more readable when you flatten your monads and give your return value a proper name instead of using a tuplecode:
|
# ? Jul 23, 2016 19:46 |
|
Why would you ever want more than:code:
|
# ? Jul 23, 2016 19:53 |
|
we need a yospos programming language thats nothing except fizz buzz lomarf and chome we can do a lot with four keywords right?
|
# ? Jul 23, 2016 20:08 |
|
BiohazrD posted:we need a yospos programming language thats nothing except fizz buzz lomarf and chome something like this https://esolangs.org/wiki/ook!
|
# ? Jul 23, 2016 20:15 |
|
LordSaturn posted:we need to stop expanding C++, it's 2016 and you can just use a good language if you loving want to People use C and then they're like "ugh I hate doing vtables by hand, maybe I'll just use a little bit of C++ but program it as if it were C" "I'll just do a little meth, I'm a strong-willed person with lots of self control, it can't be that much of a slippery slope, can it?"
|
# ? Jul 23, 2016 20:17 |
|
LordSaturn posted:we need to stop expanding C++, it's 2016 and you can just add whatever feature you want using boost spirit/phoenix
|
# ? Jul 23, 2016 20:32 |
|
Chamook posted:Why would you ever want more than: because top level type inference is awful. leave inference where it belongs (lets inside a function) and be explicit with your interface
|
# ? Jul 23, 2016 20:36 |
|
Mr Dog posted:People use C and then they're like "ugh I hate doing vtables by hand, maybe I'll just use a little bit of C++ but program it as if it were C" Worked for me!
|
# ? Jul 23, 2016 20:40 |
|
|
# ? May 25, 2024 13:27 |
|
Asymmetrikon posted:because top level type inference is awful. leave inference where it belongs (lets inside a function) and be explicit with your interface but ultimately every let is a let inside a function (main :: string array -> int)
|
# ? Jul 23, 2016 20:41 |