[REF] Move daoName generation so we don't need to pass the variable name

[eileenmcnaughton]

Overview

Minor code cleanup - rather than pass around the name of the dao class just figure it out from the entity name when needed. This has the added benefit that we can declare the class in a way IDEs recognise

Before

 public function copyDataToNewBlockDAO(string $daoName, $otherBlockId, $name, $blkCount) {

After

  public function copyDataToNewBlockDAO($otherBlockId, $name, $blkCount) {

Technical Details

$name is the name of the entity - I thought about renaming but in follow up patches I can remove most references to it so I've left for now

Comments

Note that we can remove some variables now - I've excluded from this PR as they clash with #18500

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[colemanw]

Looks like line 1812 above (which defines the now-unused variable $daoName) is no longer needed.

[eileenmcnaughton]

@colemanw - yes - removing that in this PR makes it confllct with the one in the PR template

[colemanw]

Hmm, I just removed a long switch statement like this in #18546. Aside from the $entity being the nonstandard lowercase, is there any reason not to do it this way?

Suggested change

	switch ($entity) {
	case 'email':
	return new CRM_Core_DAO_Email();
	case 'address':
	return new CRM_Core_DAO_Address();
	case 'phone':
	return new CRM_Core_DAO_Phone();
	case 'website':
	return new CRM_Core_DAO_Website();
	case 'im':
	return new CRM_Core_DAO_IM();
	default:
	// Mostly here, along with the switch over a more concise format, to help IDEs understand the possibilities.
	throw new CRM_Core_Exception('Unsupported entity');
	}
	return CRM_Core_DAO_AllCoreTables::getFullName(CRM_Core_DAO_AllCoreTables::convertEntityNameToCamel($entity, TRUE));

[eileenmcnaughton]

@colemanw yeah - the follow on patches do more by adding extra variables in there

As an aside, I think a switch in it's own function is not bad for readability - it's the long switch in the midst of a function that is

[colemanw]

Ok I'll trust you on this one.