Search Ideas

Hiccdown methods should live in their own, separate classes. How about they are called ‘displays’?

1
2
3
4
5

class ProductsDisplay
  def index vc, # …
    vc.some_helper_method
  end
end

Behind the scenes, the Hiccdown gem would need to make the instance variables available to the display class:

1
2
3
4
5
6
7
8

display = @display_module.new

view_context.instance_variables.each do |iv|
  display.instance_variable_set(
    iv,
    view_context.instance_variable_get(iv)
  )
end

Then:

1
2
3
4
5

class ProductsDisplay
  def index vc, # …
    vc.some_helper_method(@products)
  end
end

They are: vc.instance_variable_get(:@foo)

Hiccdown methods should live in their own, separate modules. How about they are called ‘displays’?

1
2
3
4
5

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.

Tested, it works.

Test this!

Then how would you call index from a helper method?

Hiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?

1
2
3
4
5

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.

Then how would you call this from a helper method?

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

1

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

I would do

1

@helper_module.send(@action_name, view_context)

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

1
2
3
4
5

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.

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.

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:

1
2

ProductsHelper.index
StoresHelper.index

Hiccdown methods should live in Rails helpers as instance methods.

Hiccdown methods should live in Rails helpers.

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.

If an already-born person is deadly ill, that doesn’t mean you can kill them.

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.

For non-viable pregnancies, where a doctor reasonably predicts that the baby will die during pregnancy or shortly after, abortions should be allowed throughout the entire pregnancy to avoid unnecessary suffering for parents and child.

This take does not address the issue of non-viable pregnancies.

Imagine being pregnant and looking forward to becoming a parent. However, during a routine diagnostic test, your doctor tells you your pregnancy isn’t viable; at birth, your baby will likely not survive long outside the womb. Because you live in a state like Texas that has recently banned abortion with few exceptions, you now need to carry this pregnancy to term, carrying the grief of a non-viable fetus and likely endangering your own life in the process.

Some say that there’s a soul from the moment of conception; that the soul has a right to life.

Some people say the demarcation point should be the heartbeat.

This seems like a response to another idea (presumably #230 and/or #232), rather than a top-level idea itself. I suggest you move this idea and break it up if necessary. Mark it as a criticism to whatever ideas you end up criticizing.

But first, familiarize yourself with the current state of the discussion. Ensure that you’re making new points. These sound like points others have made before you in this discussion. Read the entire discussion before you continue. If these points are indeed duplicates, either think of new criticisms or address existing criticisms. Don’t repeat the same ideas if you can’t address preexisting issues with them.

This seems like a response to another idea (presumably #230 and/or #232), rather than a top-level idea itself. I suggest you move this idea and break it up if necessary. Mark it as a criticism to whatever ideas you end up criticizing.

But first, ensure that you’re making new points. These sound like points others have made before you in this discussion. Read the entire discussion before you continue. If these points are indeed duplicates, either think of new criticisms or address existing criticisms. Don’t repeat the same ideas if you can’t address preexisting issues with them.

This seems like a response to another idea (presumably #230 and/or #232), rather than a top-level idea itself. I suggest you move this idea and break it up if necessary. Mark it as a criticism to whatever ideas you end up criticizing.