Activity Feed

  Dennis Hackethal criticized idea #325.

Hiccdown 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
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 display, since displays have the benefit of having unambiguously resolvable method names.

#325·Dennis HackethalOP revised over 1 year ago

Instance variables are not available inside the methods.

  Dennis Hackethal criticized idea #325.

Hiccdown 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
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 display, since displays have the benefit of having unambiguously resolvable method names.

#325·Dennis HackethalOP revised over 1 year ago

I’m trying this now. Having to prepend every invocation of a helper method with vc. is getting really old really fast.

  Dennis Hackethal revised idea #316.

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

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.

Hiccdown 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
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 display, since displays have the benefit of having unambiguously resolvable method names.

  Dennis Hackethal revised criticism #322.

Tested, it works.

Tested, it works. self does indeed point to the view_context in the helper. Verified by printing object_ids.

  Dennis Hackethal addressed criticism #321.

Test this!

#321·Dennis HackethalOP, over 1 year ago

Tested, it works.

  Dennis Hackethal addressed criticism #315.

I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)

#315·Dennis HackethalOP, over 1 year ago

Test this!

  Dennis Hackethal commented on criticism #319.

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…

#319·Dennis HackethalOP, over 1 year ago

Maybe ‘Display’. ProductsDisplay

  Dennis Hackethal criticized idea #316.

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

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.

#316·Dennis HackethalOP revised over 1 year ago

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…

  Dennis Hackethal revised criticism #314.

Then how would you call this from a helper method?

Then how would you call index from a helper method?

  Dennis Hackethal revised idea #313.

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

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

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.

  Dennis Hackethal addressed criticism #314.

Then how would you call this from a helper method?

#314·Dennis HackethalOP, over 1 year ago

I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)

  Dennis Hackethal criticized idea #313.

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
#313·Dennis HackethalOP, over 1 year ago

Then how would you call this from a helper method?

  Dennis Hackethal submitted idea #313.

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
  Dennis Hackethal criticized idea #303.

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
#303·Dennis HackethalOP, over 1 year ago

That would be mixing class methods an instance methods in Rails helper modules, which typically only contain instance methods. Not idiomatic Rails usage.

  Dennis Hackethal revised criticism #308.

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:

So instead of

@helper_module.instance_method(@action_name).bind_call(view_context)

I would do

@helper_module.send(@action_name, view_context)

And the parameter list of each Hiccdown method would start accordingly:

module ProductsHelper
  def self.index vc #, …
    # …
  end
end

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:

So instead of

@helper_module.instance_method(@action_name).bind_call(view_context)

I would do

@helper_module.send(@action_name, view_context)

And the parameter list of each Hiccdown method would start accordingly:

module ProductsHelper
  def self.index vc #, …
    vc.some_helper_method
  end

  def some_helper_method
    # …
  end
end
  Dennis Hackethal revised criticism #307.

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.

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:

So instead of

@helper_module.instance_method(@action_name).bind_call(view_context)

I would do

@helper_module.send(@action_name, view_context)

And the parameter list of each Hiccdown method would start accordingly:

module ProductsHelper
  def self.index vc #, …
    # …
  end
end
  Dennis Hackethal addressed criticism #305.

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.

#305·Dennis HackethalOP revised over 1 year ago

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.

  Dennis Hackethal revised criticism #304.

Does that mean they wouldn’t have the view_context? If so, calling helper methods from inside these class methods wouldn’t be possible.

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.

  Dennis Hackethal criticized idea #303.

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
#303·Dennis HackethalOP, over 1 year ago

Does that mean they wouldn’t have the view_context? If so, calling helper methods from inside these class methods wouldn’t be possible.

  Dennis Hackethal submitted idea #303.

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
  Dennis Hackethal revised idea #300.

Hiccdown methods should live in Rails helpers.

Hiccdown methods should live in Rails helpers as instance methods.

  Dennis Hackethal criticized idea #300.

Hiccdown methods should live in Rails helpers.

#300·Dennis HackethalOP, over 1 year ago

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.

  Dennis Hackethal started a discussion titled ‘Hiccdown Development Notes’.

Notes about developing the Ruby gem Hiccdown.

The discussion starts with idea #300.

Hiccdown methods should live in Rails helpers.

  Dennis Hackethal revised idea #276.

I’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.

I’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, an 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.

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.

  Dennis Hackethal criticized idea #276.

I’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.

#276·Dennis HackethalOP revised over 1 year ago

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’.