quotable6

query

"design smell"

result-#moarvm.md

anyway, to me, the question "can I cheat here?" is a design smell that probably means I've botched it and hung someone's coat on the wrong peg

result-#p6dev.md

Found nothing!

result-#perl6-dev.md

that was seen as a design smell

result-#perl6.md

tushar: but in general, asking if something is there first is kind of a design smell; it's usually better to have an interface where the degenerate case just does nothing, or has an easily trapped failure
A role that explicitly names a class that's composing it is usually a design smell.
TreyHarris: Well, I tend to regard using proxies a lot as a design smell.
and having a named default to true is also a design smell, is it not?
But yeah, it's generally a "design smell" to want to do it.
pat_js: it's probably a design smell that junctions are being used that way in the first place
introspection is usually a design smell
TimToady: my point is, I would only consider it a design smell if it was all over a code base
introspecting the return values of subs is not a design smell if you are trying to create .md files to describe the subs :|
.oO( I don't usually, but when I do, it's a design smell )
well, I'd say use of junctions on the left of a smartmatch is probably a bit of a design smell to begin with
timotimo: besides, "bca".elems silently fails and therefor is a source of bugs and that's a design smell
i just feel like using EXPORT to solely mutate the state of my own module based on a parameter is a design smell
you can't take a rule-of-thumb like "adverbs may be a design smell" and treat it as a universal truth
TimToady: backlogging just one screen -- that's what I thought when people started talking about adverbs and design smells. but I wasn't able to verbalize it properly.
lizmat: didn't we introduce first-index and last-index because we felt "adding adverbs" was a design smell?
glad to see you here, as I actually dropped by for a 'design smell' discussion and I always enjoy reading your opinions
being able to define operators with custom associativity / precedence as a design smell
ab5tract_: I don't follow. what's being able to define things in a more custom way's got to do with design smells?
where can i find out more about this quote "as usual, the presence of a named option is a design smell"
mst: sure, like I said I won't get the way of working more on interop. I think in the case of Inline::Perl5, it either should be a part of CORE, or not be referenced by rakudo at all. This inbetween is quite a design smell to me.
Needing those is decidedly a design smell.
jnthn: I agree it's a design smell, but I think it's because there shouldn't be a .gist-avoiding 'say' candidate in the first place :P
I was always confused by the extensive use of dynamics in rakudo...isn't it bad practice to be passing stuff around "invisibly" in the dynamic scope instead of directly as arguments? seems like the same design smell you get from over-using globals
masak: whenever parameters are being passed around purely for the sake of keeping things local, I tend to think of that as a bit of a design smell (and inconvenient). I think Perl 6's dynvars let you avoid having to jump immediately to global variables in that situation.
because it is a design smell, and slow
To me it's a huge design smell.
my @a = [1,2,3] vs my @a = [1,2,3],[4,5,6] looks like a design smell to me
still a design smell
we have that design smell no matter what
too many adverbs are a design smell
the mismatched ')' feels like a design smell... ;)
TimToady: re grep vs grep-index: I always thought that it was a design smell if the return value changed depending on an attribute
whether B is considered visible would be a semantic shift, which is probably a design smell
which in itself is not an error, of course, but it is... a design smell, perhaps.
I've heard the need for them called a "design smell" on this channel.
but yeah I guess mostly what I've heard is design smell and YAGNI
japhb: because I think forcing GC is definitely a design smell.
TimToady: y'know, many people would see that many indentation levels and call it a code design smell :P .
raydiak: i'd say so. i'm not sure someone with more insight into S12 might have a different perspective, but to me wanting to do that has a bit of a design smell with it
masak: Also, the need to do a regex match in a grammar is often a design smell, and means the grammar is deficcient in some way.
And when it is, it's usually considered a design smell
looks like the current system forces us to do introspection, which is probably a design smell of some sort
yes, it's a bit of a design smell
one could argue that LEAVE is only for leaving "normally", but I don't know if that has a design smell or not
as usual, the presence of a named option is a design smell
though sometimes this feels like a design smell...like I'm trying to use 'but' to squeeze extra information where it doesn't go
lizmat: re: stuffing a magic IO::Path into IO::Handle!path when the handle wasn't generated from a file seems like a serious design smell. When you can be checking r/w bits on pipes, sockets, and other beasties, pathed filesystems are just one case among many, not the primary case.
japhb_: I think using IntStr for something that isn't two representations of the same peice of information (like "42" and 42) is probably a bit of a design smell.
and when you need to parameterize everything, that usually is a design smell that you need dynamic scoping instead
that's where I started; 1min is not composed of a number plus a postfix if you define it as a term, which is a design smell
~& and friends have to work on a specific encoding by their nature, so they currently coerce Strs to Bufs. (the spec even says such coercion is a design smell, fwiw ☺)
I really don't see a reason to encourage people to flip the polarity of "foo" like that; it's a design smell most of the time, and not worth huffmanizing the rest of the time, methinks
adverbs are sometimes a design smell
TimToady: the state of the art of reference immutability that I've read is http://irclog.perlgeek.de/perl6/2013-09-26#i_7635049 -- but (a) such an explicit solution is not for mainline Perl 6, and (b) this solution, enticing as it is, doesn't seem "done" to me. notably, the need to forbid globals seems like a design smell.
but that's probably a design smell if you need to do that in your program
but then TimToady would point out that weak references are a design smell. :)
the reason it's a design smell is that you need the opt-in from the GC to do this. so it's user code instrumenting the GC; that's a dependency going very much the wrong way.
lizmat: ":keytype" and ":of" as named parameters feel like design smell to me.
feels like a design smell.
some things work well, others... feel like design smells, or feel "not quite right".
a void* is a design smell of something that will be precised in a derived class.
special-casing of Cool is a language design smell. :/
it's kind of a design smell, to have both return and return-rw. But normal people(tm) exepct return to decontainerize
anyway, on reflection I find it ironic that people reacted so badly to the string in .delta(3, 'days'), as if it were a big design smell. because the named arg in .delta(:days(3)) is really no better.
TimToady: I'm more worried --> Nil feels like a design smell than I am about the warning, fwiw.
the fact that we're using dynamic vars to emulate what should probably be ast attributes is a design smell
:!clobber has the "flags shouldn't be True by default" design smell.
to me there's also a design smell of having a flagname that indicates a negative condition instead of a positive one.
it can certainly remain; it just feels like a design smell to me.
harmil: Conditioning on the exports of a module is a major design smell
Woodi: [backlog] using class inheritance to "just add a few more methods" is a design smell.
though STD only uses <category> in one spot, which might be a design smell
but oddly, not in method declarations, which is probably, as I say, a design smell
introspection == design smell
.oO(the making of coprolites is one way of reducing the design smell)
wanting to do so generally indicates a design smell
the need for an Any exclusion to duck mapping is a design smell to me
masak: because you've (maybe subconciously) realized it's often design smell
Radvendii: you can return a Proxy object from @a[0], but it is usually a sign of design smell if you need to do that
moritz: what? Proxy objects are a design smell now!? :)
moritz: I'm not so sure it's design smell. Being able to enforce invariants at assignment is useful.
moritz: I think in order to claim that something like a Proxy is a design smell, it'd be nice if you could say why you think so. if you said roles are a design smell, I wouldn't believe you. with Proxy, I don't know.
toebu: but... are you sure you can't find a better solution? It's usually design smell if you need that
it's considered a design smell
lue: it's generally considered a design smell to have a negatively-phrased adverb.
hmm... sort of a design smell, I think.
sorear: it's probably a design smell
that alone is a design smell.
and the problem with :no-backtrace is that it's a negatively stated named parameter, somewhat of a design smell.
pmichaud: oh, right that was the design smell.
colomon: my problem with Damian's approach is that introspection has become a design smell to me
hm, introspection a design smell. I instinctively agreed, but then I got to thinking why I agree. why is it that introspection *is* a design smell, really?
masak: I think I can kind of feel where the design smell idea comes from. Elegant code shouldn't depend on that sort of thing.
it has been said here on the channel, and I think I agree, that nameds that default to Bool::True constitute a design smell.
in general, I think the need for infobot functionality on a channel is a community design smell.
Seems like a design smell to me, but I'm sure you can violate class encapsulation if you work at it.
is it unfortunately the case that sometimes shortterm design smelliness must be tolerated to achieve whipitupitude, when *using* a language (which i think is to what chromatic was referring).. (as opposed to designing, say, Perl 6)
That's the "design smell" point to which we alluded earlier.
lue: I already gave my opinion of pragmas above. They're nearly always a design smell, or the desire for a design smell.
it's often design smell.
when you recognize that dynamic variables can also be a design smell, you'll be in good shape.
having 'does' mean two different things is a design smell
is it possible that that indicates a design smell?
ruoso: pragmas are a little bit of a design smell, like adverbs on operators
PerlJam: I didn't know we had a flag there that defaults to true. that's usually a design smell.
masak: and yet he called them design smell
"adverb as a design smell". I interpret that as "use them when nothing else can apply" not as "adbverbs are bad".
and it doesn't mean the adverbs in S09 are necessarily a design smell.
seems like a design smell...
it's not design smell, it's design rotten to the core
but such a reverse redefinition would be considered a language design smell
yes, I just need an hour or so to decide if it's a good idea or design smell :)
chromatic: Yeah, it probably would. That special list has kinda grown organically...I still sorta half feel they're a design smell as well as a performance issue.
use of Failure as a normal return value is a design smell
introspection is almost always a design smell
there are other design smell areas
seems like a design smell to me
not to mention a design smell
as a design smell trap?
moritz_: yes, they're design smell trap because they are a feature intended to patch up a bad design, which you need sometimes :)
(Wanting the same method from two different roles to be present in the same class is a design smell for sure)
mathw: this is why it feels more like a social problem to me. The problem itself is probably a design smell.
moritz_: but in that case maybe you've got design smell, as PerlJam says
I think that '.arity' and '.count' look like design smells. a bit like '.length' did.
anyway, my point is that we should treat the need for .arity and such to be a design smell
variable method names look like design smell to me, just like variable variable names
generally, having to supply a dummy variable indicates a design smell elsewhere
so having options is a bit of a design smell at times
there are a few pragmas mentioned here or there, but generally we considered the need for a pragma to be a design smell
seems like any time you throw info away you end up with a design smell of some sort or other...
re repeatedly confusing, that's well worth noting as a 'design smell'
there's a design smell there
FAQs are a design smell...
I'm starting to think that ={...} vs ={{...}} is a design smell.
I should have recognized the design smell...