p-lang thread: (now (have you (problems two)))

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »

tef: May 30, 2004; -> some l-system crap ->

Soricidus posted:

tef please stop doing ruby it's bad for you

i have come to terms with ruby

a land where eval is fine but parametric classes (i.e namedtuple) are the work of the devil

where each team uses a different environment manager and every month or so we move versions which requires a total rebuild.

aside: i can pretty much remember the incantation brew update && brew upgrade rbenv ruby-build && rbenv build .... && rbenv rehash and then gem install bundler && bundler update. i have never worked on a project before that regularly changed interpreter versions,

but then again i didn't live in a world where i hoped that this release would finally have working GC

a land of nils: lists? nil. hashes? nil. instance variables? nil. there's countless other little nils that i can never recall. there is no datetime library.

a land of odd things: respond_to? or is it responds_to? const_get not get_const. upcase but downcase. libraries but they're all in the same namespace and essentially include files for monkey patches to build dsls.

i mean, python has namespaces, sure, but ruby, well, there's an object's constants, instance methods, class methods, and unique prototypical versions of each for any object that are not inherited. then i guess you also have local variables too. there are private methods but they just mean that you don't call them directly but implicitly.

puts is a private method on Object. Every class and instance usually descends from it, and when you call puts "foo" you're calling the puts method on object which you've inherited. It's also where all your classes are stored, as constants on object. i mean, which class will be called is a fun game.

globals are bad but 100 methods on your universal base class is business as usual.

it's not a small wonder that A::B is one of the most misunderstood parts of ruby. no-one really knows how module lookup works, or explain *why* module A::B and module A; module B work differently, i mean, for what purpose should they be distinct?

on the plus side, only false and nil are false in if statements, that's nice.

# ? Sep 28, 2015 01:31

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 23:11

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

tef posted:

it's not a small wonder that A::B is one of the most misunderstood parts of ruby. no-one really knows how module lookup works, or explain *why* module A::B and module A; module B work differently, i mean, for what purpose should they be distinct?

this one drives me crazy

# ? Sep 28, 2015 01:35

Notorious b.s.d.: Jan 25, 2003; by Reene

tef posted:

it's not a small wonder that A::B is one of the most misunderstood parts of ruby. no-one really knows how module lookup works, or explain *why* module A::B and module A; module B work differently, i mean, for what purpose should they be distinct?

as with most things in ruby, the honest to god answer is that these fall out of the naive implementation: "module A::B" actually creates an "A::B" entry in the symbol table. because the interpreter is that stupid simple

a lot of the baffling poo poo in the language comes down to how easy or hard it was to bolt a feature into the interpreter

# ? Sep 28, 2015 01:35

triple sulk: Sep 17, 2014

piss: :poo poo

is the worst syntax design decision of any language ever

# ? Sep 28, 2015 03:43

MononcQc: May 29, 2007

tef posted:

i kinda hate test driven design. i'm sure people will chime in to tell me that this isn't true test driven design, but, like agile, the name is the popular bit, and knowing the name is the average level of understanding of the practice. let's call it tdd as found in the last 2 years of ruby code bases.

1. people put their assertions invariants in their tests and not in their program

it isn't so much defensive code, but code that fails fast when the invariant fails. to understand how a piece of code works you now have to look through the litany of test files for the constraints. and before anyone tells me "lol performance" i will tell them pre-emptively to go gently caress themselves: when you decide to do something for performance reasons you are implicitly agreeing that it is a bad idea to do and you're doing a bad thing to get speed.

it's little things like where you handle each edge case explicitly rather than rolling up your code and cleverly doing things. if i have to read the tests to work out what a program should be doing, odds are the code's a poo poo show.

Agreed on the performance bit, but the assertions ought to exist in code, and the test should be exercising them to make sure they take place. More or less, the way I see it, the test would make sure nobody ever removes the assertion that should be in code at any time. The same assertion more or less should sit in specification.

A codebase where the assertions sit only in code is a codebase which will see its assertions slowly taken out through refactorings and will start failing in fun ways.

Pushing this further and you may get model-checking, where you try to just entirely have a second (high-level) representation of your system or component to exercise it properly, ensure its invariants, and so on.

tef posted:

2. people use a hell of a lot of mocks and stubs and fakes

which in my experience, don't provide a lot of value or insight for their maintenance costs, even though i am sure there are three purists who will tell me that i'm conflating the names (sure!) but i mean this: if you're testing against a mock you're not testing against your code.

i have been told "well mocks help me write tests for untestable code" except now you have two problems: mocks, and bad code.

This is true. Mocks suck. The distinction I see is that a mock provides either of the following:

1. A way to return a predictable value for a non-deterministic process. Datetime testing is an example, where a mock can be used to return time values that exercise boundary conditions (leap year, DST changes, end of years, etc.) without problem. However, mocks used that way are almost always symptomatic of too tight of a coupling -- if your code operates on data rather than through APIs, you can pass the time as an argument and assume other code does the binding through. This ends up simplifying integration tests down the line.

Incidentally, the most times I'm forced to mock code is not when doing TDD, it's when writing tests for old-rear end code (as you said, 'testing untestable code') because I can't have the code testable without refactoring it, and I'm not willing to refactor without having tests to make sure I'm not breaking poo poo.

The long cycle of this is hellish and it goes write lovely tests -> refactor -> rewrite non-lovely tests. Try arguing a time budget for that.

2. Prevent outrageous resource setup. I've written mocked tests for a build tool (which is an ordeal I don't recommend getting into) where I can assume files were fetched over the network and create per-case dependency trees of packages. The alternative is setting up your own package registry, generating packages ahead of time, and running tests against them. Similarly, testing for specific external APIs or handling of network failures is far simpler by just having a mock representing the failure than by setting a remote service and hoping it fails the right way. You may still need tests to ensure actual calls work properly, but those aren't the same thing.

In many cases where I see mocks making sense, the tests and their setup can become as complex (or more complex) than the actual code you're testing. That way lies madness, enjoy your dockerific test runs. Mocking is a kind of compromise or shortcut there, where you trade the risk of a tower of babel test code for the hindrance of less maintainable test suites, given all your tests end up reflecting a reimplementation of an API that may change, and then you're forced to rewrite a bunch of tests. I still believe that often, that's a cheaper cost than maintaining test environments set up all the time, which is essentially an ops job.

3. A way to avoid duplicating tests. This is more frequent when you treat your code as specs, but they let you set invariants in a piece of code that you do not want to exercise 15 times through 15 tests. I'm not sure I like these much, but yeah.

tef posted:

3. tests slow down refactoring

this one is weird because i know a lot of you will say "not with my tests", and i guess that's true, but i've encountered a lot of tests which assert that underlying methods on different objects get called. you're not testing behaviour you're testing implementation, and when you want to change implementation you must re-write the tests. throw in that a lot of tests use fake objects and you have to rewrite numerous lines of code to re-implement the behaviour.

Incidentally, I find most tests that test implementation are those written after code, or at least the way I do it the most. It's whenever I go "okay, I feel this is good enough now, let's crystallize the gently caress out of this module to make sure it doesn't change accidentally". It's the lovely half-assed tests I end up writing when I feel my work is done and I'm too bored to return quality stuff otherwise (and why writing test first makes sense for me -- it's the best way I found to care harder about writing good tests). I also find it hard to make assumptions such as "function X gets called" when function X is not implemented yet.

The other argument I'd make is that the thing that slows down refactoring the most isn't tests, it's not having tests. Because then, I gotta make sure I reverse-engineer the behavior specifications, then write tests first before refactoring to make sure I don't actually break anything.

If you write good tests, I don't really give a fart whether they've been written before or after the face. If you omit them, though, then I hate you down the line when it comes to maintenance, because the work has just been shoveled forward for whoever touches that code next.

tef posted:

4. testing isn't free

tests are code and have maintenance, documentation burdens just like any other code, and just like any other code we shirk them. we even pretend that tests are documentation some times.

Agreed.

# ? Sep 28, 2015 04:04

JewKiller 3000: Nov 28, 2006; by Lowtax

tef posted:

who will tell you about the magic of type inference until you ask them about monomorphism restrictions and row polymorphism and they look sad

MALE SHOEGAZE posted:

can you or anyone please explain this to me because i dont understand it

ok. type inference means you almost never have to declare your types, because the compiler infers them from usage. those types may be polymorphic, i.e. instantiable in many ways. an example is the list length function, which takes a list of any type and returns the number of items in it. you can call that function with a float list, string list, int list list, etc. example in ocaml:

code:

# let rec length = function [] -> 0 | _ :: rest -> 1 + length rest;;
val length : 'a list -> int = <fun> 
# length [1; 2; 3];;
- : int = 3
# length [4.20; 24.7];;
- : int = 2
# length [["nested"]; ["lists"]];;
- : int = 2

now suppose we also have mutable types in our language, because we're not haskell noobs. consider a function that maintains a list inside a mutable reference cell, and inserts whatever item you pass to it (! is the dereference operator, like * in C):

code:

# let f =
   let r = ref [] in
   fun x ->
     r := x :: !r;
     !r;;
val f : '_a -> '_a list = <fun>

here you see the '_a instead of 'a, this is a monomorphism restriction. lists can only contain values of a single type, so it wouldn't make sense to call this function with some ints and then a char:

code:

# f 666;;
- : int list = [666]
# f 119;;
- : int list = [119; 666]
# f 'c';;
Error: This expression has type char but an expression was expected of type int

in this case the restriction makes sense, in fact you need it for the type system to be sound. however it also shows up in places where you might not expect it:

code:

# let reverse_all = List.map List.rev;;
val reverse_all : '_a list list -> '_a list list = <fun>

i'm getting the '_a, even though these are all pure functions. normally this is not a big deal because you just do an eta-expansion and everything is fine:

code:

# let reverse_all l = List.map List.rev l;;
val reverse_all : 'a list list -> 'a list list = <fun>

if you want to read more about this restriction you can check out a page like http://users.cis.fiu.edu/~smithg/cop4555/valrestr.html. but really it's a solution, not a problem, and no one is sad about it

row polymorphism is great poo poo, you can basically do statically enforced "duck typing" with it, and i have no idea why tef doesn't like it

JewKiller 3000 fucked around with this message at 04:13 on Sep 28, 2015

# ? Sep 28, 2015 04:11

Sapozhnik: Jan 2, 2005; Nap Ghost

tef posted:

6. gently caress cucumber

this is a bonus but i've only encountered this flagellation under tdd rubyism. let's write our tests like a click through license, and then write a series of regular expressions to convert them into ruby assertions

i'd ask if you were kidding but i mean this is ruby we're talking about

# ? Sep 28, 2015 04:43

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

Mr Dog posted:

i'd ask if you were kidding but i mean this is ruby we're talking about

it's true.

# ? Sep 28, 2015 04:47

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

JewKiller 3000 posted:

a good post

thanks, i really appreciate this post. i'm going to take some time to read it.

# ? Sep 28, 2015 04:54

MononcQc: May 29, 2007

I find the idea of cucumber hilariously bad. One more installment of 'plain English can be turned to code so that anyone can write this' that is bound to fail.

# ? Sep 28, 2015 05:03

tef: May 30, 2004; -> some l-system crap ->

MononcQc posted:

Agreed on the performance bit, but the assertions ought to exist in code, and the test should be exercising them to make sure they take place. More or less, the way I see it, the test would make sure nobody ever removes the assertion that should be in code at any time. The same assertion more or less should sit in specification.

I like this.

Pushing this further and you may get model-checking, where you try to just entirely have a second (high-level) representation of your system or component to exercise it properly, ensure its invariants, and so on.

quote:

This is true. Mocks suck. The distinction I see is that a mock provides either of the following:

1. A way to return a predictable value for a non-deterministic process.

I guess I am ok with things that stub out data *i.e. idempotent* but not things that stub out other sorts of behaviour

quote:

Incidentally, the most times I'm forced to mock code is not when doing TDD, it's when writing tests for old-rear end code (as you said, 'testing untestable code') because I can't have the code testable without refactoring it, and I'm not willing to refactor without having tests to make sure I'm not breaking poo poo.

The long cycle of this is hellish and it goes write lovely tests -> refactor -> rewrite non-lovely tests. Try arguing a time budget for that.

The thing is what when you mock behaviour, you don't get it right. these tests are a cheap facade that resembles the mess and will be based upon your understanding of the system, and not the implementation. You end up with false confidence and weird bugs anyhow, but it's good for catching the regressions you know about.

I've had to use a lot of large third party libraries, and i could have easily tested against mocks but so, so many bugs came from the subtle manipulations of data in the sprawlling mess of a million lines of code that i would never be able to capture with mocks.

You might be easier off writing integration tests against a known state to give you the confidence, rather than mocking out parts of the dependencies and crossing your fingers. Then again, It's often cheaper to rewrite it and suffer over if the code is broken enough or you have to rewrite most of it to fix the bugs anyhow.

quote:

2. Prevent outrageous resource setup. I've written mocked tests for a build tool (which is an ordeal I don't recommend getting into) where I can assume files were fetched over the network and create per-case dependency trees of packages. The alternative is setting up your own package registry, generating packages ahead of time, and running tests against them.

testing should be approached end-to-end and then optimized in the middle. your mocks give you a quick feedback loop but i hope you still run the full suite.

quote:

Similarly, testing for specific external APIs or handling of network failures is far simpler by just having a mock representing the failure than by setting a remote service and hoping it fails the right way. You may still need tests to ensure actual calls work properly, but those aren't the same thing.

Fault injection is lovely but it isn't really the same class of testing as mocking. Again going back to the "if you're faking idempotent behaviour then i guess it's cool"".

# ? Sep 28, 2015 05:28

tef: May 30, 2004; -> some l-system crap ->

JewKiller 3000 posted:

row polymorphism is great poo poo, you can basically do statically enforced "duck typing" with it, and i have no idea why tef doesn't like it

yes i like it a lot but guess how many programming languages advocated by static typing enthusiasts support it ? nominative subtyping is for chumps

# ? Sep 28, 2015 05:33

triple sulk: Sep 17, 2014

MALE SHOEGAZE posted:

it's true.

https://blog.codecentric.de/en/2013/08/cucumber-setup-basics/

code:

Given(/^a cucumber that is (d+) cm long$/) do |arg1|
  pending # express the regexp above with the code you wish you had
end

When(/^I cut it in halves$/) do
  pending # express the regexp above with the code you wish you had
end

Then(/^I have two cucumbers$/) do
  pending # express the regexp above with the code you wish you had
end

Then(/^both are (d+) cm long$/) do |arg1|
  pending # express the regexp above with the code you wish you had
end

# ? Sep 28, 2015 05:46

triple sulk: Sep 17, 2014

i'm loving glad that ruby is dead. it's garbage and i can't believe that there are people who have suffered from stockholm syndrome so badly that they're working on rails apps in 2015. holy poo poo.

# ? Sep 28, 2015 05:49

comedyblissoption: Mar 15, 2006

MononcQc posted:

I find the idea of cucumber hilariously bad. One more installment of 'plain English can be turned to code so that anyone can write this' that is bound to fail.

What ends up happening with these frameworks is that you are now writing your tests in a really bad dynamically typed programming language with extreme amounts of boilerplate and more obnoxious debugging.

# ? Sep 28, 2015 05:52

comedyblissoption: Mar 15, 2006

When writing tests, try to create as little mocks as possible. Move the mocks to the outer boundaries of the system (e.g. file system, web service calls). If you make it so every class or small module mocks everything that it interacts with in your tests, you will make it difficult to change your system later and you aren't meaningfully testing the integration of the parts of your system which is extremely important.

# ? Sep 28, 2015 05:53

jony neuemonic: Nov 13, 2009

cucumber is the worst and i'm glad i talked work into dropping it.

# ? Sep 28, 2015 05:55

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

comedyblissoption posted:

When writing tests, try to create as little mocks as possible. Move the mocks to the outer boundaries of the system (e.g. file system, web service calls). If you make it so every class or small module mocks everything that it interacts with in your tests, you will make it difficult to change your system later and you aren't meaningfully testing the integration of the parts of your system which is extremely important.

well, yes, but that would be integration testing. if you're doing unit testing, then you're gonna need to mock.

# ? Sep 28, 2015 05:55

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

tef posted:

yes i like it a lot but guess how many programming languages advocated by static typing enthusiasts support it ? nominative subtyping is for chumps

it is a solution that addresses a mostly insignificant facet of the actual problem and encourages programmers to stick to bad code-design decisions

here is the actual problem: i have a function, and i want to pass it values of different types that share a common interface

row polymorphism helps when the types are (1) record types that (2) have real fields with (3) exactly the same names as each other and (4) exactly the same types as each other, but might have extra fields, and (5) the only common functionality the function wants to rely on is the presence of those fields, (6) which it will read out while ignoring the rest of the value

constrained polymorphism via signatures / interfaces / protocols / type-classes generalizes this solution so much better than row-polymorphism that it is absolutely hilarious that people keep dicking around with it. its sole advantage is if you literally have a ton of interesting projection functions with completely different ad-hoc constraints, and guess what, you don't. meanwhile it encourages you to stick with lovely unencapsulated anonymous record types with redundant information storage in order to have the right set of fields for different row-polymorphic functions

# ? Sep 28, 2015 06:03

MononcQc: May 29, 2007

MALE SHOEGAZE posted:

well, yes, but that would be integration testing. if you're doing unit testing, then you're gonna need to mock.

The trick would be to write your units such as they are independent and decomposed so that rather than needing to mock their internal dependencies, you change their inputs only.

Functional programmers come out of the woodworks about now and gloat about taking a data-centric approach.

The holy grail there is to have a bunch of well tested (without mocks) independent components -- meaning low coupling and easier reuse -- and just assemble them together. When you test that assembled whole, that's your integration tests, and no mocking is ever needed.

This is more wishful thinking than an actual plan though, but whenever you hit a mock, it's worth considering whether you're coupling components more than they need to be.

# ? Sep 28, 2015 06:04

JewKiller 3000: Nov 28, 2006; by Lowtax

tef posted:

yes i like it a lot but guess how many programming languages advocated by static typing enthusiasts support it ? nominative subtyping is for chumps

there are probably more, but the only one i can think of is (of course) ocaml:

code:

# let add_foo_and_bar x = x#foo + x#bar;;
val add_foo_and_bar : < bar : int; foo : int; .. > -> int = <fun>

the static type doesn't give a poo poo what class i created x from, only what methods it has. i can create an object from a compatible class and it'll work:

code:

# class foobar (f:int) (b:int) = object method foo = f method bar = b end;;
class foobar : int -> int -> object method bar : int method foo : int end
# let x = new foobar 1 2;;
val x : foobar = <obj>
# add_foo_and_bar x;;
- : int = 3

or an unrelated class, with no inheritance establishing subtyping, it just provides the necessary methods:

code:

# class unrelated (x:int) = object method whatever = x method foo = x - 1 method bar = x - 2 end;;
class unrelated : int -> object method bar : int method foo : int method whatever : int end
# add_foo_and_bar (new unrelated 4);;
- : int = 5

i can even use a literal object with no class at all:

code:

# add_foo_and_bar (object method foo = 69 method bar = 420 end);;
- : int = 489

# ? Sep 28, 2015 06:11

JewKiller 3000: Nov 28, 2006; by Lowtax

rjmccall posted:

constrained polymorphism via signatures / interfaces / protocols / type-classes generalizes this solution so much better than row-polymorphism that it is absolutely hilarious that people keep dicking around with it.

good languages don't use row polymorphism as their sole source of constrained polymorphism. i agree that duck typing is a bad code-design decision, but there sure seem to be a lot of people who disagree, and it'd be nice to introduce static types to those people

# ? Sep 28, 2015 06:17

brap: Aug 23, 2004; Grimey Drawer

mocking is not that big of a deal but people seem to have a habit of overdoing it once they discover it.

even if you're doing a functional approach and data is king, you're still gonna want to compose functions together where some of those functions involve making a network request or accessing storage or whatever non-deterministic thing, and you want to be able to pass those kinds of functions in as dependencies so that you can have tests that use deterministic implementations of those functions.

# ? Sep 28, 2015 06:28

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

JewKiller 3000 posted:

good languages don't use row polymorphism as their sole source of constrained polymorphism. i agree that duck typing is a bad code-design decision, but there sure seem to be a lot of people who disagree, and it'd be nice to introduce static types to those people

you still don't need row polymorphism, though. if you're going to add language features to appeal to duck-typers, give them implicit conformance, i.e. let the language figure out that type A satisfies all the constraints of some signature instead of making them write that explicitly. it's row polymorphism except it encourages them to recognize and name their protocols and actually gives them a path forward towards better code design, instead of encouraging them to write a bunch of code that will need to be majorly restructured if they ever want to move away from anonymous record types

# ? Sep 28, 2015 06:36

tef: May 30, 2004; -> some l-system crap ->

rjmccall posted:

it is a solution that addresses a mostly insignificant facet of the actual problem and encourages programmers to stick to bad code-design decisions

constrained polymorphism via signatures / interfaces / protocols / type-classes generalizes

how many of the type classes use existential types? how many generic parameters are covariant or contravariant ? how many of the classes implement a protocol or a signature?

a lot of the code that is typed is not typed in the cleanest way possible without a clean break between abstract interfaces and concrete classes. i have regularly been plagued by concrete types where interfaces ought to be. and tbh i am not going to maintain invasive upstream modifications on a third party code base when all i wanted to do was pass in a "list like object".

it's not that i like row polymorphism but it is that i despise nominative subtyping. i really really like structural subtyping. i really like polymorphism. i am willing to go to treacherous lengths to achieve this, including duck typing

# ? Sep 28, 2015 06:59

fart simpson: Jul 2, 2005; DEATH TO AMERICA

tef posted:

yes i like it a lot but guess how many programming languages advocated by static typing enthusiasts support it ? nominative subtyping is for chumps

elm has row polymorphism and it seems pretty good to me idk

# ? Sep 28, 2015 07:58

Edison was a dick: Apr 3, 2010; direct current only

MononcQc posted:

I find the idea of cucumber hilariously bad. One more installment of 'plain English can be turned to code so that anyone can write this' that is bound to fail.

A friend of mine wrote Yarn inspired by Cucumber, for testing programs where the interface is shell commands.

It worked well for him, but I think the benefit wasn't the english language description of the test steps, more that it was a form of Literate programming, which produced a test suite which also served as documentation and specification.

I'm hoping I can sneak tests into the next project where I have to work with Mr "testing is bad" by calling them stories.

# ? Sep 28, 2015 09:12

Xarn: Jun 26, 2015

tef posted:

3. tests slow down refactoring

this one is weird because i know a lot of you will say "not with my tests", and i guess that's true, but i've encountered a lot of tests which assert that underlying methods on different objects get called. you're not testing behaviour you're testing implementation, and when you want to change implementation you must re-write the tests. throw in that a lot of tests use fake objects and you have to rewrite numerous lines of code to re-implement the behaviour.

I see your method call assertions and raise you checking non-atomic call counters from different thread. :shepicide:

# ? Sep 28, 2015 16:59

gonadic io: Feb 16, 2011; >>=

Edison was a dick posted:

I'm hoping I can sneak tests into the next project where I have to work with Mr "testing is bad" by calling them stories.

Incidentally this is how Dynamic Programming got such a generic non-mathsy name.

# ? Sep 28, 2015 18:36

EVGA Longoria: Dec 25, 2005; Let's go exploring!

i use ruby every day and it's p ok

i would kill for static typing, interfaces, and the death of monkey patching

# ? Sep 28, 2015 18:44

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

sometimes i read these posts about row polymorphism and go "what the gently caress is this look at these smart fellers"

then i remember it's just writing a c++ thing that takes a class type as a template argument and relies on that class type to have a given function or it breaks horribly and i think remember that 99.99999999999% of thetime a well-named interface is better

# ? Sep 29, 2015 03:01

fart simpson: Jul 2, 2005; DEATH TO AMERICA

imagine this http://www.haskellforall.com/2012/05/scrap-your-type-classes.html plus row polymorphism. thats elm's current approach to "interfaces"

# ? Sep 29, 2015 04:13

Ralith: Jan 12, 2011; I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Phobeste posted:

sometimes i read these posts about row polymorphism and go "what the gently caress is this look at these smart fellers"

then i remember it's just writing a c++ thing that takes a class type as a template argument and relies on that class type to have a given function or it breaks horribly and i think remember that 99.99999999999% of thetime a well-named interface is better

Row polymorphism gives you the error up front instead of exploding into a million shards of angry templates. Still not a great way to structure a system, though.

# ? Sep 29, 2015 05:25

brap: Aug 23, 2004; Grimey Drawer

basically interfaces + implicit implementation of interface members = what the gently caress are you complaining about, row polymorphailures

# ? Sep 29, 2015 05:29

cowboy beepboop: Feb 24, 2001

i wrote some php today and lol @ comments that affect the code

code:

class PostController extends Controller
{
    /**
     * @Route("/")
     */
    public function indexAction()
    {
        // ...
    }
}

# ? Sep 29, 2015 08:13

karms: Jan 22, 2006; by Nyc_Tattoo; Yam Slacker

lol @ aspect oriented programming

whats that, typo3 or something?

# ? Sep 29, 2015 08:43

Soricidus: Oct 21, 2010; freedom-hating statist shill

my stepdads beer posted:

i wrote some php today and lol @ comments that affect the code
code:
class PostController extends Controller
{
    /**
     * @Route("/")
     */
    public function indexAction()
    {
        // ...
    }
}

wish your postcontroller routed to /dev/null

# ? Sep 29, 2015 09:59

jony ive aces: Jun 14, 2012; designer of the lomarf car; Buglord

from pages ago b/c i don't understand any of this recent stuff about cucumbers

Fergus Mac Roich posted:

noob question but you can just set the onClick listener or w/e for a particular view in code in the fragment as opposed to the xml, right? i'm writing my first android app and i think that's what i'm going with rather than making GBS threads up my activity with random fragment-related methods.

oh yeah that makes sense actually

by which i mean it totally doesn't make any loving sense at all but i bet that's probably how they made it do things. i remember seeing some idiot xamarin thing where i think there was some type of method that had like a whole different signature depending on whether it was defined in xml or code so wouldn't be surprised if android does something almost as dumb

Flat Daddy posted:

angualr toStrings your function at runtime, so if you minified first then it will see 'a' or w/e instead of '$http' and it won't work.

that's dumb, instead of minifying just use a real programming language and compile to bytecode instead, problem solved :smuggo:

# ? Sep 29, 2015 10:21

jony neuemonic: Nov 13, 2009

my stepdads beer posted:

i wrote some php today and lol @ comments that affect the code
code:
class PostController extends Controller
{
    /**
     * @Route("/")
     */
    public function indexAction()
    {
        // ...
    }
}

eh, symfony is one of the few php things that isn't completely clown-town. i can't really hate on it.

# ? Sep 29, 2015 16:30

Adbot: ADBOT LOVES YOU

# ? Jun 10, 2024 23:11

Soricidus: Oct 21, 2010; freedom-hating statist shill

jony neuemonic posted:

eh, symfony is one of the few php things that isn't completely clown-town. i can't really hate on it.

is that like giving hitler due credit for the autobahns?

# ? Sep 29, 2015 20:48

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > p-lang thread: (now (have you (problems two)))

«‹›1784 »