Activity feed
#325 · Dennis Hackethal, 3 months agoHiccdown methods should live in their own, separate modules. How about they are called ‘displays’?
module ProductsDisplay def self.index vc, # … vc.some_helper_method end endA benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a display, since displays have the benefit of having unambiguously resolvable method names.
Instance variables are not available inside the methods.
#325 · Dennis Hackethal, 3 months agoHiccdown methods should live in their own, separate modules. How about they are called ‘displays’?
module ProductsDisplay def self.index vc, # … vc.some_helper_method end endA benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a display, since displays have the benefit of having unambiguously resolvable method names.
I’m trying this now. Having to prepend every invocation of a helper method with vc. is getting really old really fast.
Hiccdown methods should live in their own, separate modules. How about they are called‘renderers’?↵ ↵ ```ruby↵ module ProductsRenderer↵‘displays’?↵ ↵ ```ruby↵ module ProductsDisplay↵ def self.index vc, # …5 unchanged lines collapsedA benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in arenderer,display, sincerenderersdisplays have the benefit of having unambiguously resolvable method names.
Tested, it works. `self` does indeed point to the `view_context` in the helper. Verified by printing `object_id`s.#315 · Dennis Hackethal, 3 months agoI don’t think that’s something people would do a lot, but they still easily could:
ProductsRenderer.index(self)
Test this!
#319 · Dennis Hackethal, 3 months agoI don’t like the term ‘renderer’ yet. It’s too loaded with meaning, what with Rails already having a
rendermethod in controllers and anotherrendermethod in views…
Maybe ‘Display’. ProductsDisplay
#316 · Dennis Hackethal, 3 months agoHiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?
module ProductsRenderer def self.index vc, # … vc.some_helper_method end endA benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a renderer, since renderers have the benefit of having unambiguously resolvable method names.
I don’t like the term ‘renderer’ yet. It’s too loaded with meaning, what with Rails already having a render method in controllers and another render method in views…
6 unchanged lines collapsedend↵ end↵ ```end↵ end↵ ```↵ ↵ A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a renderer, since renderers have the benefit of having unambiguously resolvable method names.
I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)
#313 · Dennis Hackethal, 3 months agoHiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?
module ProductsRenderer def self.index vc, # … vc.some_helper_method end end
Then how would you call this from a helper method?
Hiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?
module ProductsRenderer
def self.index vc, # …
vc.some_helper_method
end
end
#303 · Dennis Hackethal, 3 months agoHiccdown methods should live in Rails helpers as class methods. That way, the problem described in #302 is solved – methods can be referenced unambiguously:
ProductsHelper.index StoresHelper.index
That would be mixing class methods an instance methods in Rails helper modules, which typically only contain instance methods. Not idiomatic Rails usage.
19 unchanged lines collapsedvc.some_helper_method↵ end↵ ↵ def some_helper_method↵ # …3 unchanged lines collapsed
If so, there might be a way to bind them to the `view_context`. Or I could definitely pass the `view_context` explicitly as the firstparameter.parameter:↵ ↵ So instead of↵ ↵ ```ruby↵ @helper_module.instance_method(@action_name).bind_call(view_context)↵ ```↵ ↵ I would do↵ ↵ ```ruby↵ @helper_module.send(@action_name, view_context)↵ ```↵ ↵ And the parameter list of each Hiccdown method would start accordingly:↵ ↵ ```ruby↵ module ProductsHelper↵ def self.index vc #, …↵ # …↵ end↵ end↵ ```
#305 · Dennis Hackethal, 3 months agoDoes that mean they wouldn’t have access to the
view_context? If so, calling helper methods from inside these class methods wouldn’t be possible.
If so, there might be a way to bind them to the view_context. Or I could definitely pass the view_context explicitly as the first parameter.
Does that mean they wouldn’t have access to the `view_context`? If so, calling helper methods from inside these class methods wouldn’t be possible.
#303 · Dennis Hackethal, 3 months agoHiccdown methods should live in Rails helpers as class methods. That way, the problem described in #302 is solved – methods can be referenced unambiguously:
ProductsHelper.index StoresHelper.index
Does that mean they wouldn’t have the view_context? If so, calling helper methods from inside these class methods wouldn’t be possible.
Hiccdown methods should live in Rails helpers as class methods. That way, the problem described in #302 is solved – methods can be referenced unambiguously:
ProductsHelper.index
StoresHelper.index
Hiccdown methods should live in Railshelpers.helpers as instance methods.
That isn’t a good idea because Hiccdown methods often share the same conventional names (index, show, etc), which can and does lead to conflict.
Notes about developing the Ruby gem Hiccdown.
Hiccdown methods should live in Rails helpers.
6 unchanged lines collapsedClearly,a fetusan embryo without a nervous system can’t be sentient and thus can’t be a person, right? And as long as it’s not a person, it doesn’t have any rights.4 unchanged lines collapsed
#276 · Dennis Hackethal, 3 months agoI’m pro abortion but I have some pro life in me.
Banning the abortion of a zygote seems ridiculous. So does aborting a seven-month-old fetus.
Why not go with: you can abort until the nervous system develops.
Clearly, a fetus without a nervous system can’t be sentient and thus can’t be a person, right? And as long as it’s not a person, it doesn’t have any rights.
According to https://www.neurosciencefoundation.org/post/brain-development-in-fetus, “an embryo’s brain and nervous system begin to develop at around the 6-week mark.” And: “At as early as 8 weeks (about 2 months), you can see physical evidence of the brain working (the electric impulses) as ultrasounds show the embryo moving.”
This idea is for viable pregnancies only. Other considerations may apply for non-viable ones.
Clearly, a fetus without a nervous system can’t be sentient and thus can’t be a person, right?
It’s not considered a fetus until week 9, at which point the nervous system has already begun building.
The correct word to use here is ‘embryo’.